Thanks! This project is interesting to remove bits that shouldn't be there in the first place, but that's not really my question.

I'm ok (for now) with including all of MS.Data.SqlClient in my application, without any kind of trimming for this lib.

I'd like to still be able to use the dotnet trimming feature for the rest of my app.

There are documented options here:
https://learn.microsoft.com/en-us/dotnet/core/deploying/trimming/trimming-options?pivots=dotnet-8-0

And I've tried to go back to the previous default of partial for TrimMode, I've tried rooting MS.Data.SqlClient with TrimmerRootAssembly but it didn't work.

I'd like an example of a csproj configuration where .net 8 trimming works in a project using SqlClient (understanding that SqlClient itself can't be trimmed, but the rest should).

Hi,
Did you ever get anywhere with getting this to work?
I've been trying to get a trimmed self contained app working on .NET 9 and getting TypeInitializationExceptions when it does some SSL setup in TDSParser, and as you say, setting trim mode and rooting the SqlClient assembly doesn't help.

Marking System.Private.CoreLib as a root assembly does seem to help, but I haven't worked out exactly what it is that's getting trimmed when it shouldn't yet

Found a small (~2MB) improvement here https://dlosch.github.io/dotnet/sql-server/aot/trimming/2025/08/22/SqlClient.html

<linker>
 <assembly fullname="System.Private.CoreLib">
 <type fullname="System.StubHelpers.InterfaceMarshaler" preserve="all"/>
 </assembly>
</linker>

As of 7.0.0-preview1, it's technically possible to use RuntimeHostConfigurationOption to set the UseManagedNetworkingOnWindows AppContext switch. This will allow the IL trimmer to remove the unused SNI (whether this is managed or native.)

<RuntimeHostConfigurationOption Include="Switch.Microsoft.Data.SqlClient.UseManagedNetworkingOnWindows" value="true" />

Setting this to true will force SqlClient to use the managed SNI and remove all references to the native SNI, setting it to false will do the opposite.

With this being said: SqlClient doesn't officially support trimming. The RuntimeHostConfigurationOption approach is undocumented because it doesn't completely unlock the feature.

A handful of features aren't trim-compatible at all:

• The native SNI isn't statically linked to the finished EXE (which also blocks untrimmed single-file publishing.)
• Using System.Configuration to dynamically load a type based on app.config will be hit-and-miss at best. The use of System.Configuration can't be trimmed because it's the only way to define LocalDB instance versions.
• User-defined CLR types don't work, and I don't think will be able to work without a new library API of some kind to register the type - SQL Server sends the type information as a string at runtime, long after the linker has done its work.

@peterhirn @edwardneal Great tips to help with using MSSQL in small tools, thanks!

It feels like those limitations should be documented and we should be able to trim as long as we don't use LocalDB nor user-defined CLR types.

Blocking that scenario completely because a few edge-cases are not supported is sad.