Unable to load 5.1.1 DLL 'Microsoft.Data.SqlClient.SNI.x64.dll' : The specified module could not be found.

[kumar-pandey]

Hi,
Myself Kumar Kashyap Pandey working in .NET core (4.7.2) application and to implement Azure Active Directory authentication adding MicroSoft.Data.SqlClient for it and as per dependency MicroSoft.Data.SqlClient.SNI is also getting added but its dll is not getting loaded throwing error like Unable to load DLL 'Microsoft.Data.SqlClient.SNI.x64.dll': The specified module could not be found.

Exception

Microft SQL Client 5.1.1 refereced in Project

SNI file not accessible error although it has read and execute access for all users.

Project bin folder with sql client dlls

In Packages folder

Microsft data client dlls in Package config

Kindly help me ASAP for resolving this issue.

[Kaur-Parminder]

@kumar-pandey This looks like similar known issues reported earlier: #2024 #1318 #745 . You should not be adding direct dependency to Microsoft.Data.SqlClient.x64.dll, it is an internal dependency of M.D.S.

I tried WebApp(MVC) netframework472 and did not see issue though, I added MDS reference to WebApp and open connection. It looks like workaround discussed here also when MDS is referenced to webapp directly #2024 (comment).
Can you provide repro and detail steps for your scenario? Can you also share if you see dll in the Publish folder.

[kumar-pandey]

@kumar-pandey This looks like similar known issues reported earlier: #2024 #1318 #745 . You should not be adding direct dependency to Microsoft.Data.SqlClient.x64.dll, it is an internal dependency of M.D.S.

I tried WebApp(MVC) netframework472 and did not see issue though, I added MDS reference to WebApp and open connection. It looks like workaround discussed here also when MDS is referenced to webapp directly #2024 (comment). Can you provide repro and detail steps for your scenario? Can you also share if you see dll in the Publish folder.

@Kaur-Parminder Thanks for considering the issue, I can't share the repo as it is a org private repo but yes for detail we want to authenticate the application through azure active directory, for that we adding the Microsoft.Data.SqlClient through Nugget package and yes the dependency dll (SNI dll) also getting installed in nugget package and its also coming in bin folder will all 86, 64 version but it can't be loaded in project. So, for trial to add that SNI dll with manual reference also through project folder but that also not worked.
Let me know if you want more details. Thanks.

[Kaur-Parminder]

@kumar-pandey Please provide details steps of how you are creating Application (Type of project) and deploying/publishing would help. if Repro is not available.

Issue reported earlier of ASP.Net/deployment are related to octopus packaging, WPF or multiple project structures and have respective workarounds. The SNI DLLs are downloaded to your bin folder when restoring/building the project if you have MDS reference. I believe you have them. Please insure you clean project before you are testing any changes.

I have created webapp(netframework472 and Microsoft.Data.SqlClient.5.1.1) and sqlclient seem to work fine. it is attached. I am hosting it locally through Visual studio 2022/2019 (IIS express).

WebApplication2dllloading.zip

[Luxed]

I'm having the same issue. Trying to update our old Web Forms application and related libraries to use Microsoft.Data.Sql Client instead of System.Data.SqlClient.
The UI project has the SqlClient package as a dependency.
It always has the Microsoft.Data.SqlClient.dll file in the bin/ directory.
It sometimes doesn't have the SNI dlls in the bin directory.

After a little bit of investigation, I have found a very consistent way of reproducing the issue:

1. Use Visual Studio 2022 on Windows
2. Create a new ASP.NET Web Forms project (in my case, .NET Framework 4.7.2)
3. Add the Microsoft.Data.SqlClient dependency to the Web project
4. Rebuild in Visual Studio
5. SNI dll files are included in the bin/ directory
6. Quit Visual Studio
7. Delete the packages/, WebApplication/bin/ and WebApplication/obj/ directories
   NOTE: We have a script to do that sometimes because Nuget, Visual Studio or something else might fail somewhere and create weird issues. This cleans everything and ensures you're building from a truly clean state.
8. Go back into Visual Studio and Rebuild the project
9. At this point, the SNI.dlls are not in the bin/ directory

It might be important to note that building the project with msbuild works every time.

[Luxed]

After more investigation on my side, I have found something else.

The following part in the target:

  <ItemGroup>
    <SNIDllFiles Condition="'$(MSBuildThisFileDirectory)' != '' And
                                    HasTrailingSlash('$(MSBuildThisFileDirectory)')"
                        Include="$(MSBuildThisFileDirectory)**\Microsoft.Data.SqlClient.SNI.*.dll" />
    <SNIFiles Condition="'$(MSBuildThisFileDirectory)' != '' And
                                   HasTrailingSlash('$(MSBuildThisFileDirectory)')"
                        Include="$(MSBuildThisFileDirectory)**\Microsoft.Data.SqlClient.SNI.*"
                        Exclude="$(MSBuildThisFileDirectory)**\*.targets" />
  </ItemGroup>

Seem to be returning empty lists when the bug appears.
I have tried this:

1. Clean the project as described in step 7 of the previous post
2. Modify the Microsoft.Data.SqlClient.SNI.targets file to include this after the ItemGroup:

  <Target Name="SNITest" AfterTargets="AfterBuild">
    <Message Text="Files: @(SNIFiles)" />
    <Message Text="DLL Files: @(SNIDllFiles)" />
  </Target>

3. Open Visual Studio
4. Rebuild the project
5. Observe in the output (if your verbosity is high enough) that the SNIFiles and SNIDllFiles lists are empty

This means that none of the proposed "workarounds" currently work for me.
Instead, I will have to add a post-build script that explicitly copies the DLLs to every project's output directories.

[kumar-pandey]

Thanks Luxed for guiding for resolving my issue

I followed the steps as you suggested, it not worked for me, sharing the change details for target file detail in .csproj file for your verification.
<Project> <ItemGroup> <AdditionalFiles Include="..\..\.sonarlint\iccm\CSharp\SonarLint.xml"> <Link>SonarLint.xml</Link> </AdditionalFiles> </ItemGroup> <Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" /> <Import Project="..\..\packages\Microsoft.Data.SqlClient.SNI.5.1.0\build\net462\Microsoft.Data.SqlClient.SNI.targets" Condition="Exists('..\..\packages\Microsoft.Data.SqlClient.SNI.5.1.0\build\net462\Microsoft.Data.SqlClient.SNI.targets')" /> <Target Name="SNITest" AfterTargets="AfterBuild"> <Message Text="Files: @(SNIFiles)" /> <Message Text="DLL Files: @(SNIDllFiles)" /> </Target> <!-- To modify your build process, add your task inside one of the targets below and uncomment it. Other similar extension points exist, see Microsoft.Common.targets. <Target Name="BeforeBuild"></Target><Target Name="AfterBuild"></Target> --> </Project>

Please verify, if it is correct.
Thanks,
Kumar

[Luxed]

Thanks Luxed for guiding for resolving my issue
Please verify, if it is correct. Thanks, Kumar

I'm not able to fix the issue either. The steps I wrote are only here to help reproduce the issue.

[Kaur-Parminder]

@Luxed Thanks for providing detail steps. I could see error if I follow steps given above.

@Luxed @kumar-pandey after looking around more similar issues I think this is packages.config to PackageReference migration issue. Can you try make changes here: Options->NuGet Package Manager that the default package management format is PackageReference AND "Allow formation selection on first package install" is checked.
it worked consistently fine for me. if I delete bin/obj/package --> open visual studio -- build solution --> Run application

Although in above repro steps if I just clean than build on step 8 it still works. but with NP Manager changes you just have to build it.

[kumar-pandey]

@Kaur-Parminder Thanks for sharing the additional steps, I tried the same steps of NP Manager but it couldn't work for me, still having the same issue, hoping positively.

[Luxed]

I think this is packages.config to PackageReference migration issue

PackageReference is simply not an option when talking about a Web Forms project. This has been discussed and documented at large. Visual Studio also stops you from converting a Web Forms project to PackageReference.

Can you try make changes here: Options->NuGet Package Manager that the default package management format is PackageReference AND "Allow formation selection on first package install" is checked.

I tried enabling "Allow format selection on first package install", but it did not change anything. And on top of that, it's also a Visual Studio/Nuget setting, so it wouldn't be suited for a development team.

This is quite a weird issue especially since I have another dependency that does a similar kind of thing (grpc, it bundles non C# dlls when building) and that one works every time.

For now, on my side, I have a documented workaround: If I build the application, then close Visual Studio, then reopen it, then build the application again, then it works for every future build (so long as you don't remove the packages directory).
This will be annoying during the transition from System.Data.SqlClient to Microsoft.Data.SqlClient, but it will eventually be less of an issue.

[kurt-m]

Have you tried 5.1.0? Comparing the packages the targets files are identical but 5.1.1 is missing the dlls in the transitive folder. The CopySNIFiles target is not locating any SNI files to copy.

[lordscarlet]

The problem I have is this is an issue on the build server, so it never has the /packages/ folder already, so all of the pitfalls of deleting the folder as described above happen regardless.

[gilmorem560]

Just adding in here I am seeing this happen with 5.2.0 of Microsoft.Data.SqlClient.SNI involved, but if I downgrade to 5.1.1, I do get the SNI.x64 DLL in my build. This is for a .NET 4.8 project. Not sure if that helps any, I can't provide the project as a ref due to ownership.

If I discover anything else in my case I'll report back.

[jzabroski]

@Luxed , thanks for your comment here: #2049 (comment)

Have you tried taking an msbuild binary log file and viewing it in MSBuild Structured Log Viewer tool? https://msbuildlog.com/

I am curious if you see the same behavior I describe here: dotnet/msbuild#10973 (comment)