Inject Application Name to SQL Server connection string when not set #36548
Conversation
There was a problem hiding this comment.
Pull Request Overview
This PR implements automatic injection of application name information into SQL Server connection strings when not explicitly set by the user. The application name includes EF Core version, OS details, framework information, and SqlClient version to aid in monitoring and diagnostics.
- Adds automatic Application Name injection to SQL Server connections containing EF Core and environment details
- Modifies connection string handling to preserve user-defined Application Names while adding EF defaults when missing
- Includes comprehensive test coverage for both connection string and DbConnection scenarios
Reviewed Changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 4 comments.
| File | Description |
|---|---|
src/EFCore.SqlServer/Storage/Internal/SqlServerConnection.cs |
Core implementation adding connection string modification logic and Application Name injection |
test/EFCore.SqlServer.Tests/Storage/Internal/SqlServerConnectionTest.cs |
Test coverage for Application Name injection scenarios and helper method for existing tests |
test/EFCore.SqlServer.Tests/Storage/Internal/SqlServerConnectionTest.cs
Outdated
Show resolved
Hide resolved
|
Hmm, test failures indicate that unfortunate there's a 128-char limit on Application Name (The value's length for key 'Application Name' exceeds its limit of '128'). So instead of a nice long |
|
@roji Could you note use a shorther representation of the SqlClient version? |
roji
force-pushed
the
SqlClientConnectionString
branch
2 times, most recently
from
a36ce56 to
daf752b
Compare
|
@AndriySvyryd @cincuranet @ErikEJ pushed changes to only rewrite when the user configures EF with a connection string, as discussed, should be ready for review. |
| // Application Name with EF and versioning info. | ||
| // Note that we don't do anything if EF was configured with a SqlConnection, as that could reset the | ||
| // password because of Persist Security Info=true | ||
| var relationalOptions = RelationalOptionsExtension.Extract(dependencies.ContextOptions); |
There was a problem hiding this comment.
I don't love that we need to extract the options here again (or the smelly assignment from ConnectionString to ConnectionString), but RelationalConnection works hard to prevent implementations from ever knowing if it was configured with a connection string or connection and generally to implement this kind of feature.
I'd propose some refactorings here, but this is temporary throwaway code, since SqlClient will be including a first-class user-agent-like feature anyway - so as a stop-gap this seems ok...
|
LOTM |
roji
force-pushed
the
SqlClientConnectionString
branch
from
daf752b to
f41e45e
Compare
roji
force-pushed
the
SqlClientConnectionString
branch
from
f41e45e to
38632ed
Compare
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
3 participants
Note: this support via the connection string is temporary and is likely to go away in EF 11 once SqlClient introduce a more first-class user-agent-like mechanism (see #35730 (comment)).
Closes #35730