Runtime: Failed to load sni.dll

[foxjazz]

Posted project here:
https://github.com/foxjazz/gadgetWebApi.git

Created asp.net 2.0 core app with a controller that opens a connection sqlConnection. when this happens error is here but only on a 2008 r2 server the app is published to. The app runs fine on developer machine. but does not publish correctly and even if code is copied, still failes on 2008R2 server.

[ERR] Connection id ""0HL7B69PSCNQ2"", Request id ""0HL7B69PSCNQ2:00000001"": An unhandled exception was thrown by the application. (560e7d32)
System.DllNotFoundException: Unable to load DLL 'sni.dll': The specified module could not be found. (Exception from HRESULT: 0x8007007E)
at System.Data.SqlClient.SNINativeMethodWrapper.UnmanagedIsTokenRestricted(IntPtr token, Boolean& isRestricted)
at System.Data.Win32NativeMethods.IsTokenRestrictedWrapper(IntPtr token)

[karelz]

Does it happen on more than one machine? Looks like invalid installation to me ..

@corivera @divega can you please take a look?

[divega]

@foxjazz can you try adding an explicit reference to the new SqlClient package? e.g.:

<PackageReference Include="System.Data.SqlClient" Version="4.4.0" /> 

You should use this version to run correctly across all architectures in .NET Core 2.0, which is better explained at https://github.com/Azure/app-service-announcements-discussions/issues/9, but it seems Dapper is pulling an older version as a dependency.

[divega]

Adding a reference to Microsoft.AspNetCore.All would also fix it, although I assume you may have decided not to do that.

[foxjazz]

Thanks. Problem is now fixed with an asp.net core update.
More notes on the behavior. occurred only when running dotnet abc.dll and not under iis Express.

Thanks for jumping on it.
Joe

[karelz]

@divega do we understand how customer code can get into the 'bad' situation above? Is it one off or something more people will hit?

[divega]

@karelz I think others (cc @corivera, @ericstj) understand much better what is going on. But my understanding is this: SqlClient requires this native assembly sni.dll and if you are using a previous version of the package than 4.4 you may end up with a assembly for the wrong RID deployed.

I think anything that gets the newer SqlClient package into more applications can help. If you follow ASP.NET Core and EF Core 2.0 install/upgrade instructions, you’ll get the right version. Perhaps if Dapper was updated with the new dependency, that would help too.

cc @NickCraver

[NickCraver]

I've updated Dapper to 4.4.0 on the netstandard2.0 chain (.csproj link - not yet built for release, maybe next week), should we be pushing this for our netstandard1.3 users as well? I'm not opposed to this, we just generally take a widest-compat stance as a library often does by default. But if there's good reason to upgrade, I'm happy to do so.

[divega]

Looks like SqlClient 4.4.0 should work with .NET Standard 1.3 all right, but I will let @corivera and others answer.

[foxjazz]

I updated the aspnetcore.all and the problem went away. Still using dapper 1.50.2 which wasn't the issue at all. The issue was the connection. currently there isn't a way to repro it. And it wasn't working TODAY after a restore of aspnetcore version 2. But as soon as I added the .All things were working. I hope this helps.

[willbuildapps]

The solution pointed by @divega solve the issue to here!

[joseclament]

I've a web job and its getting the same exception, but I am not using Microsoft.AspNetCore.All.
Using netcoreapp2.1 and runtimeIdentifiers are win10-x64;osx.10.11-x64 Any idea?

[karelz]

@joseclament please do not cross-post, especially not on closed issues. If you have a problem, create isolated repro, put together current behavior description vs. expected and file a new issue. The description you provide above does not seem to be sufficient.