SqlClient: Update to Microsoft.Data.SqlClient 2.0.0 breaks a self-contained .NET Core 3.1 ServiceFabric service
We have a ServiceFabric service, which is running the latest .NET Core 3.1. We publish & deploy it as self-contained. It references Microsoft.Data.SqlClient. Using version 1.1.3 everything works perfectly. After updating to 2.0.0, we can not event deploy it to the fabric anymore. Unfortunataly, ServiceFabric gives very little information why. This is what we see:
Service package for manifest 'XXXX' and service package activation ID 'XXXX' is in Error.
'System.Hosting' reported Error for property 'ServiceTypeRegistration:XXX'.
The ServiceType was disabled on the node.
It tries that several times and then gives up. By digging into SF events i was able to find this as well:
There was an error during CodePackage activation.The process/container terminated with exit code:2147516556.
By comparing service package i can see that it used to include sni.dll when using 1.1.3 and then its gone after we updated to 2.0.0. My suspicion is that is the reason why the service fails to start.
And i think is my theory is correct because the service works just fine locally, since sni.dll is availaible on my PC. But it does not exist on the ServiceFabric’s VMs.
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Comments: 32 (17 by maintainers)
I think since we also shipped the PDBs to Microsoft.Data.SqlClient.SNI Nuget (SNI for .NET Framework), we packaged it here too for consistency, but I agree the experience hasn’t been great with .NET Core. I’ll take it offline and see if we can take them away and only upload them on symbol server.
I had this issue too with a .NET Core app using Entity Framework Core 5.0.0 packaged as a single exe. I solved it by explicitly taking a dependency on
Microsoft.Data.SqlClientversion 2.1.0 (which depends onMicrosoft.Data.SqlClient.SNI.runtime>= 2.1.1):Hi @dmytro-gokun
Just a heads up, we’re setup and planning to fix this issue with next preview release of Microsoft.Data.SqlClient v2.1.0-preview2, will keep you posted.
Rolling the entity framework nuget packages back to 3.1.8 fixed the problem on the .NET 5 rtm release for me.
Hi @dmytro-gokun
Closing this issue as pdbs have been removed from Microsoft.Data.SqlClient.SNI.runtime v2.1.1 to be picked by Microsoft.Data.SqlClient v2.1.0-preview2 onwards.
For 1.1.3 it didn’t happen because we referenced “runtime.native.System.Data.SqlClient.SNI” NuGet that did not contain PDBs. Reason why there were complaints regarding missing PDBs.
@cheenamalhotra In my humble opinion, Azure DevOps does the right thing: they treat debug info as debug info. By requiring a pdb to be present for an app to start, you are essentially changing the semantic of what pdb is. IMO.