0

I'm having trouble bringing in class libraries which have recently been migrated to NetStandard2.0 into an old-style AspNet web application project (framework 4.7.2).

The updated assemblies reference NuGet package Microsoft.Data.SqlClient v5.1.0

When running, the app generates the following error trace when attempting to open a SQL connection:

The type initializer for 'Microsoft.Data.SqlClient.TdsParser' threw an exception.

The type initializer for 'Microsoft.Data.SqlClient.SNILoadHandle' threw an exception.

Unable to load DLL 'Microsoft.Data.SqlClient.SNI.dll': The specified module could not be found. (Exception from HRESULT: 0x8007007E)

Sure enough, there is no instance of Microsoft.Data.SqlClient.SNI.dll in the output bin folder - screenshot below - but there are instances of x64, x86 and arm64 dlls.

What's been tried:

  • Adding NuGet package Microsoft.Data.SqlClient v5.1.0 package directly into the web application project.

  • Located this resource which recommends that a .targets file (from the Microsoft.Data.SqlClient package) is explicitly referenced in the application's .csproj file, but doesn't elaborate on how to do that.

  • Located this question which asks almost the same question, and have attempted to incorporate the following tag in the application's .csproj file, but with no apparent effect or further diagnostic output:

    <Target Name="_CopySNIFilesToWebProjectOutputDir" AfterTargets="CopySNIFiles" Condition="'$(WebProjectOutputDir)' != ''">
  <Copy SourceFiles="@(SNIFiles)" DestinationFiles="@(SNIFiles -> '$(WebProjectOutputDir)\bin\%(RecursiveDir)%(Filename)%(Extension)')" />
</Target>

  • Specified x64 as target platform. No impact.

I'm now at a loss for further avenues to pursue. How do I get Microsoft.Data.SqlClient.SNI.dll into my application's bin folder?

SqlClient dlls output

Neil Moss
  • 6,598
  • 2
  • 26
  • 42
  • Do you use packages.config or package reference in this project file? The latter is required. – Lex Li Mar 07 '23 at 23:04
  • Package reference is used. – Neil Moss Mar 08 '23 at 09:16
  • Then the situation is rather tricky. Microsoft seems to want legacy project types to go back to packages.config (so if you try to ask VS2022 to “Migrate packages.config to PackageReference” it refuses). I tested a clean ASP.NET 4.x project in VS2022 with packages.config and cannot reproduce the exception. The output folder contains exactly the files in your screen shot. – Lex Li Mar 08 '23 at 22:26
  • That's the problem - the file Microsoft.Data.SqlClient.SNI.dll should _also_ be output. It's the file that the exception is reporting cannot be found. – Neil Moss Mar 09 '23 at 09:08
  • No. That file `xxx.SNI.dll` does not need to exist like I said at all. You got the exception because of something else (like I said might be related to PackageReference). – Lex Li Mar 09 '23 at 09:16
  • I don't understand then. Why have I got an error saying "cannot find xxx.SNI.dll" if xxx.SNI.dll does not need to exist? – Neil Moss Mar 09 '23 at 17:51
  • Exception message can be misleading in certain situation, and that's not a surprise. So, don't trap yourself and you can think out of the box. Like I said, if you you now create a clean web project with `packages.config` and try to reproduce this issue, you might simply find that it doesn't exist there. – Lex Li Mar 09 '23 at 20:31

1 Answers1

0

We had a similar problem and solved it by using the solution from your third point. Our setup is ASP.NET Framework 4.7.2 project with dependency on .Net Standard 2.0 project (logging with Serilog to MsSql).

  <Target Name="CopySNIFilesToOutputPath" AfterTargets="CopySNIFiles" Condition="'$(WebProjectOutputDir)' != ''">
    <Copy SourceFiles="@(SNIFiles)" DestinationFiles="@(SNIFiles -> '$(WebProjectOutputDir)\bin\%(RecursiveDir)%(Filename)%(Extension)')" />
  </Target>
drpdrp
  • 2,351
  • 3
  • 11
  • 15