Could not load file or assembly 'Microsoft.Data.SqlClient.SNI.x64.dll' or one of its dependencies. The module was expected to contain an assembly manifest.

[OzzProjects]

Describe the bug

I have a WinForms application. I need to use 'Microsoft.Data.SqlClient' package for SQLClient connections.
The former package is a managed assembly and it depends on this Native SNI Library: 'Microsoft.Data.SqlClient.SNI'
The native SNI library is referenced by referencing the '.targets' file in an import statement in the '.csproj' file.

<Import Project="packages\Microsoft.Data.SqlClient.SNI.4.0.0\build\net46\Microsoft.Data.SqlClient.SNI.targets" Condition="Exists('packages\Microsoft.Data.SqlClient.SNI.4.0.0\build\net46\Microsoft.Data.SqlClient.SNI.targets')"/>

When the application is cleaned and then built, the bin folder in the debug folder contains the following:
Microsoft.Data.SqlClient.SNI.x64.dll
Microsoft.Data.SqlClient.SNI.x64.pbg
Microsoft.Data.SqlClient.SNI.x86.dll
Microsoft.Data.SqlClient.SNI.x86.pbg

To me that means, the reference towards the target file works and it has copied the dll's.

If I purposely run the application.exe file to test or I publish the project. This exception is being prompted:

Could not load file or assembly 'Microsoft.Data.SqlClient.SNI.x64.dll' or one of its dependencies. The module was expected to contain an  assembly manifest.
File name: 'Microsoft.Data.SqlClient.SNI.x64.dll'  ---> System.BadImageFormatException: Could not load file or assembly 'Microsoft.Data.SqlClient.SNI.x64.dll'  or one of its dependencies. The module was expected to contain an assembly manifest.
File name: 'Microsoft.Data.SqlClient.SNI.x64.dll'

Official documentation stating to reference like this: Here

To reproduce

Create a WinForms application.
Import Microsoft.SQLServer.SqlManagementObjects version 161.46521.71 through : 'Manage Nuget packages for solution'
Import Microsoft.Data.SqlClient version 4.0.0 through : 'Manage Nuget packages for solution'
Import Microsoft.Data.SqlClient.SNI if it does not import automatically with Microsoft.Data.SqlClient.
Clean the solution.
Rebuild the solution.
Open the bin folder.
Open the debug folder.
Run the application.exe file.

Expected behavior

To run the application without the exception.

Further technical details

Microsoft.Data.SqlClient version: 4.0.0
.NET target: Framework 4.8
SQL Server version: SQL Server 2017
Operating system: Windows 10

Questions

Why do I receive that exception despite the presumed correct reference of .targets file?

Am I referencing the SNI. dll correctly? If not what is the correct way of doing so?

What is the difference between the build and buildTransitive folder?

Are the Microsoft.Data.SqlClient.SNI.x64 and x86 dll meant to be deleted from the bin folder?

How is this issue prevented upon publishing?

[OzzProjects]

If anyone stumbles on this issue, try the opposite. I decided to remove the import statement in the .csproj file ; which copies the SNI files as references into the project. (Comment it out).

I do not know why SNI files are copied on the first place. You can access your .csproj file by : right clicking the your project, unload the project, right click project again, edit .csproj file.

Make sure to remove the SNI dll that were imported previously too in your bin/debug folder.

[Dyllanjrusher]

Hey,
I know this is closed but I wanted to answer some of these questions as I've ran into the same issue just a few days ago.

If you're working with a solution that has multiple projects in it, MDS doesn't do well with referencing transitive dependencies.

What is a transitive dependency?
Suppose you have three projects A, B, C.

Say A depends on MDS. B references A, and then C references B. B has a direct dependency to MDS, and C has a transitive dependency to MDS.

What worked for me, given I had a this transitive dependency, was to just install the package via nuget to project C. I think this is an issue that has been solved in .net Core as it's better at dealing with transitive dependencies.

This is an interesting read for how .net Core handles the situation.
https://www.erikheemskerk.nl/transitive-nuget-dependencies-net-core-got-your-back/