Inject Application Name to SQL Server connection string when not set#36548
Inject Application Name to SQL Server connection string when not set#36548roji merged 1 commit intodotnet:mainfrom
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? |
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 |
daf752b to
f41e45e
Compare
f41e45e to
38632ed
Compare
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
| // detect that and overwrite. | ||
| if (connectionStringBuilder.ApplicationName is "Core Microsoft SqlClient Data Provider" or "" or null) | ||
| { | ||
| var efVersion = FileVersionInfo.GetVersionInfo(Assembly.GetExecutingAssembly().Location).ProductVersion; |
There was a problem hiding this comment.
Should be replaced with this in order to be single-file deployment compliant:
var efVersion = typeof(SqlServerConnection).Assembly.GetCustomAttribute<AssemblyInformationalVersionAttribute>()?.InformationalVersion;I had already reported a similar issue in Microsoft.PowerPlatform.Dataverse.Client a few years ago: microsoft/PowerPlatform-DataverseServiceClient#257 (comment) (except there wasn't a try/catch) 😉
There was a problem hiding this comment.
@0xced I'd like to fix this, but can you provide a bit more context on what the exact problem is? Is FileVersionInfo somehow incompatible with single-file deployments, is ProductVersion somehow less reliable than AssemblyInformationalVersionAttribute? Any pointers to resources on this would be appreciated.
There was a problem hiding this comment.
With single-file deployment, the EF Core assembly is bundled into the app host executable, so Assembly.GetExecutingAssembly().Location returns an empty string. This is documented in the Assembly.Location property (remarks):
In .NET 5 and later versions, for bundled assemblies, the value returned is an empty string.
Then, calling FileVersionInfo.GetVersionInfo("") throws System.ArgumentException: The path is empty. (Parameter 'path')
Using AssemblyInformationalVersionAttribute works for both standard and single-file deployments.
There was a problem hiding this comment.
But are those not completely different data structures??
There was a problem hiding this comment.
But are those not completely different data structures??
There was a problem hiding this comment.
From what I understand by reading the source code of the FileVersionInfo class, FileVersionInfo.ProductVersion contains exactly the same value as the AssemblyInformationalVersion attribute when this attribute exists.
[...] unless there is an AssemblyInformationalVersionAttribute, in which case it always uses that for the product version [...]
Reading the whole LoadManagedAssemblyMetadata method seems to confirm this too.
It seems pretty safe to me to use the AssemblyInformationalVersionAttribute to retrieve the EF Core version.
Also, typeof(SqlServerDbContextOptionsExtensions).Assembly.GetCustomAttribute<AssemblyInformationalVersionAttribute>()?.InformationalVersion returns 10.0.1 which is exactly what we expect.
There was a problem hiding this comment.
There was a problem hiding this comment.
LGTM, thanks for the detailed explanation @0xced
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