Sni.dll not included in .NET Core 3.x.x shared folder

[RomBrz]

We are using .NET Core in our applications, but with .NET Core 3.x.x we start to have problems that "sni.dll missing". Seems like when using it, the library put the sni.dll inside of the code itself, and this give me problems as we use the security recomendations to use permissions as little as possible (Read Only with Application Pool Identity), so the application in 3.x.x crashes as it try to execute the dll.

In .NET Core 2.x, when you install a Server Bundle, sni.dll comes with the Core as "shared dll", so any process could execute there. In .NET Core 3.x didn't come.

Workound: i copied the sni.dll from "C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App\2.2.8" to "C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App\3x.x" and the applications running .NET Core 3.x.x could run with "Read Only" permission on project folder (the same behavior that works with 2.x.x projects).

I already opened this issue in .NET Core git, but they told me that is a SQL thing
dotnet/aspnetcore#18266

[cheenamalhotra]

In .NET Core 2.x, when you install a Server Bundle, sni.dll comes with the Core as "shared dll", so any process could execute there. In .NET Core 3.x didn't come.

Hi @RomBrz

.NET Core 3.x onwards the new SqlClient library "Microsoft.Data.SqlClient" is used, and it is certainly not the same as before since SNI.dll are now referenced from external packages. But I'm a little confused how SNI.dll was integrated before and shipped with ASP.NET Core App.

@ajcvickers
Could you shed some light on how System.Data.SqlClient and SNI.dll were included before in the working ANC.App v2.2.8 (C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App\2.2.8) as I'm looking at SNI.dll and System.Data.SqlClient.dll properties and are they .NET Framework DLLs?

In order to understand which SNI.dll library is getting pulled for Microsoft.Data.SqlClient now, I need some background of how ASP.NET integrates with SqlClient.

[cheenamalhotra]

@RomBrz

I think you might also need to migrate to the new namespace "Microsoft.Data.SqlClient" in order to work with ASP.NET Core 3.x, if not done yet. If your code still references System.Data.SqlClient, that could be the reason it looks for sni.dll in the loaded runtime libraries and works when copied manually.

@ajcvickers please correct me if I'm wrong.

[RomBrz]

Hi @cheenamalhotra , thanks for helping me with that.
We are using Microsoft.Data.SqlClient in all our .NET Core 3.1 projects, and we're having the same problems, as Microsoft.Data.SqlClient searches for sni.dll in the same folders as System.Data.SqlClient.

My problem is related with permissions and availability of the DLLs. Let my try to explain better:

Before .net core 3.0 there were a sni.dll in C:\Program Files (x86)\dotnet\shared\Microsoft.AspNetCore.App\2.2.8, for example, and when i install that on my server, this folder by default has basicaly "Read and Execute" permission for almost everyone, so any application could execute any DLL that exists in this folder. With .NET Core 3.x, the sni.dll don't existis in this shared folder, and the code put that sni.dll in it's own folder.

Let me exemplify the default behavior:
App1 running with .NET Core 2.1.15:
C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App\2.1.15\sni.dll (folder with Read and Execute permission)
C:\Inetpub\App1 (folder with Read only)
The application runs fine with Read only permission, as App1 try to find and execute sni.dll from shared folder.

App2 running with .Core 3.1.1:
C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App\3.1.1\sni.dll (folder with Read and Execute permission) DON'T EXIST
C:\Inetpub\App2\runtimes\win-x64\native\sni.dll was created when building the project
C:\Inetpub\App2 (folder with Read only)
The application don't run, as i need to give "\native" Read and Execute permission to run.

So with the .NET Core 3.x behavior i have more insecure applications as, to work, i have to give more NTFS permissions to run the "same" code.

My workaround is simply get the sni.dll and put inside the C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App\3.1.1\sni.dll, so the App2 in my example will run with "Read Only".

Seems like with .NET Core 3.x Microsoft choose to not use sni.dll as a "common dll that should be in default shared dlls" and who wants to use it should put inside your code (and with that opening a security flaw as giving NTFS permission to Execute inside a code isn't a best practice).

TL: sni.dll come in .NET 2.x shared folder when you install the server bundle. .NET 3.x didn't come with sni.dll in shared folder, forcing who want's to use to publish inside the project's folder, and with that forcing to give more permissions that should be needed to run compared with an 2.x project.

[ajcvickers]

@cheenamalhotra With regard to the SNI dependency, this isn't something I am very familiar with. It is likely something that @danmosemsft's team knows more about. @bricelam might also have some ideas.

With regards to using ASP.NET Core 3.x, yes, that requires updating to "Microsoft.Data.SqlClient". (This is, of course, assuming that you're using some part of ASP.NET Core that does data access, such as Identity or EF.)

[danmoseley]

I wasn't aware of any change to sni.dll deployment between 2.1 and 3.1. Maybe @ericstj can recall.

[ericstj]

We've never included sni.dll in Microsoft.NETCore.App. This has always shipped as a dependency of the SqlClient package: https://www.nuget.org/packages/runtime.native.System.Data.SqlClient.sni/

It looks like ASP.NET core previously included SqlClient in Microsoft.AspNetCore.App, but then removed it in 3.0. That's the reason for this observed change.

It was brought in by Microsoft.EntityFrameworkCore.SqlServer and Microsoft.Extensions.Caching.SqlServer, so the changes to these two components in 3.0 are what caused the removal of sni.dll from the AspNetCore shared framework.

[RomBrz]

Is there a way to solve this? What is the permission recomendations for running a in proc asp.net core site in iis?
I like to suggest asp.NET Core team do something (as .NET Core still a "new thing") about this "breaking changes" (i don't know if this should be the place, but..):

1. How about define what should be the minimum permission needed to run asp.NET Core applications?
2. Considering that this is defined and should be the default, how to deal with this kind of problems?
   .NET Core should be (for what i've heard) making version upgrades less problematic.. but a simple change from .NET 2.2.8 to 3.0.0 caused me two big breaking changes on hosting:
   a) A common dll, to most of my applications, to comunicate with SQL Server just "gone" from it's default behavior;
   b) The first breaking change approach, to put the dll inside the code folder, gave me the second breaking change: my published code just stopped working with "Read Only" permission.
   c) With a few exceptions, majority of the systems that i manage on many servers (.NET 2.0, .NET 4.0, .NET Core 2.0, .NET Core 3.0) always run with "Read Only" permission on respective App Pool Identity user. This is the best secure practice from Microsoft... Why don't keep this approach (very secure) with future .NET Core versions (in case, mandatory for library design).

[cheenamalhotra]

Hi @RomBrz

Related question I had for you.. how to do you usually manage permissions for Dependent DLLs that are loaded by NuGet packages referenced?

The change of package from System.Data.SqlClient > Microsoft.Data.SqlClient seems to be the motivation to remove SNI.dll from shared libs, as Microsoft.Data.SqlClient is now an independent library but also needs to reference SNI.dll from another NuGet package in order to work.

[RomBrz]

Hi! @cheenamalhotra
The "default behavior" for all of ours applications is to use "Read Only". Each project we start with a website created at IIS, with respective application pool using "AppPool Identity" mode, and with "IIS AppPool\APPPOOLNAME" NTFS permission at home directory for the site.
Some legacy projects buit in 2005-2010 for example, using .NET 2.0 or even 4.0, was made executing dlls or writing something in disk, so we have some folders in these projects with "Read and Execute" or even "Modify".
More recently, for what i can record, we had problems when "Roslyn" start to need "Execution" permissions. I than give "Execute" to the HOME/bin/roslyn/csc.exe (with everything else working with Read only), but after a time the developers start to use it with another way that didn't need more this permission.
With .NET Core, all projects by default works with Read only permission to entire folder. For what i understood talking with the devs, seems like some libraries made this need to "execute dlls".
Than, we start to have problems with some projects asking for more permissions (after my investigation, i come with some projects needing "Traverse" permission on home directory only, instead of just "Read only" to home and entire folder.
Seems like sni.dll works in different way, asking more components and permissions.. Than it works fine until devs starts to work with .NET Core 3.0.
As i told, by "default" i would need to give Execution to the dll folder at each .NET Core 3.0 projects, but i discover that by design the .NET Core try to find dlls on shared folder, so right now to keep the projects with Read only i was copying manually the "sni.dll" from .NET Core 2.x folder to the 3.0.x and 3.1.x folders, and thinking that i would change the Release pipeline on Azure DevOps eventually to made every project that need one DLL to copy that "at each release" to the shared folder, if more projects and more libraries start to ask Execute permission.
We use here the .NET Core "In Process", handled by IIS 10 (Win 2019).
The last recomendation i get from Microsoft is to keep minimium permissions, so the minimum should be for me Read only at home directoly only (each project with it's own exclusive permission it it's own home folder so if i ever try to change AppPools will give permission denied).

[simonauner]

We're seeing the same issue with a .NET Core 3.1.101 project, using Microsoft.EntityFrameworkCore 3.1.2 and Microsoft.EntityFrameworkCore.SqlServer 3.1.2, built on Ubuntu 18.04 (both on my local machine and on Azure Pipelines Virtual Machines (link to machine spec: https://github.com/actions/virtual-environments/blob/master/images/linux/Ubuntu1804-README.md)).

System.TypeInitializationException : The type initializer for 'Microsoft.Data.SqlClient.TdsParser' threw an exception.
  ----> System.TypeInitializationException : The type initializer for 'Microsoft.Data.SqlClient.SNILoadHandle' threw an exception.
  ----> System.DllNotFoundException : Unable to load shared library 'sni.dll' or one of its dependencies. In order to help diagnose loading problems, consider setting the LD_DEBUG environment variable: libsni.dll: cannot open shared object file: No such file or directory
   at Microsoft.Data.ProviderBase.DbConnectionPool.TryGetConnection(DbConnection owningObject, UInt32 waitForMultipleObjectsTimeout, Boolean allowCreate, Boolean onlyOneCheckConnection, DbConnectionOptions userOptions, DbConnectionInternal& connection)
   at Microsoft.Data.ProviderBase.DbConnectionPool.TryGetConnection(DbConnection owningObject, TaskCompletionSource`1 retry, DbConnectionOptions userOptions, DbConnectionInternal& connection)
   at Microsoft.Data.ProviderBase.DbConnectionFactory.TryGetConnection(DbConnection owningConnection, TaskCompletionSource`1 retry, DbConnectionOptions userOptions, DbConnectionInternal oldConnection, DbConnectionInternal& connection)
   at Microsoft.Data.ProviderBase.DbConnectionInternal.TryOpenConnectionInternal(DbConnection outerConnection, DbConnectionFactory connectionFactory, TaskCompletionSource`1 retry, DbConnectionOptions userOptions)
   at Microsoft.Data.ProviderBase.DbConnectionClosed.TryOpenConnection(DbConnection outerConnection, DbConnectionFactory connectionFactory, TaskCompletionSource`1 retry, DbConnectionOptions userOptions)
   at Microsoft.Data.SqlClient.SqlConnection.TryOpen(TaskCompletionSource`1 retry)
   at Microsoft.Data.SqlClient.SqlConnection.OpenAsync(CancellationToken cancellationToken)
--- End of stack trace from previous location where exception was thrown ---
   at Microsoft.EntityFrameworkCore.Storage.RelationalConnection.OpenDbConnectionAsync(Boolean errorsExpected, CancellationToken cancellationToken)
   at Microsoft.EntityFrameworkCore.Storage.RelationalConnection.OpenDbConnectionAsync(Boolean errorsExpected, CancellationToken cancellationToken)
   at Microsoft.EntityFrameworkCore.Storage.RelationalConnection.OpenAsync(CancellationToken cancellationToken, Boolean errorsExpected)
   at Microsoft.EntityFrameworkCore.Update.Internal.BatchExecutor.ExecuteAsync(IEnumerable`1 commandBatches, IRelationalConnection connection, CancellationToken cancellationToken)
   at Microsoft.EntityFrameworkCore.Update.Internal.BatchExecutor.ExecuteAsync(IEnumerable`1 commandBatches, IRelationalConnection connection, CancellationToken cancellationToken)
   at Microsoft.EntityFrameworkCore.ChangeTracking.Internal.StateManager.SaveChangesAsync(IList`1 entriesToSave, CancellationToken cancellationToken)
   at Microsoft.EntityFrameworkCore.ChangeTracking.Internal.StateManager.SaveChangesAsync(DbContext _, Boolean acceptAllChangesOnSuccess, CancellationToken cancellationToken)
   at Microsoft.EntityFrameworkCore.SqlServer.Storage.Internal.SqlServerExecutionStrategy.ExecuteAsync[TState,TResult](TState state, Func`4 operation, Func`4 verifySucceeded, CancellationToken cancellationToken)
   at Microsoft.EntityFrameworkCore.DbContext.SaveChangesAsync(Boolean acceptAllChangesOnSuccess, CancellationToken cancellationToken)

dotnet --info outputs the following:

→ dotnet --info
.NET Core SDK (reflecting any global.json):
 Version:   3.1.101
 Commit:    b377529961

Runtime Environment:
 OS Name:     ubuntu
 OS Version:  18.04
 OS Platform: Linux
 RID:         ubuntu.18.04-x64
 Base Path:   /usr/share/dotnet/sdk/3.1.101/

Host (useful for support):
  Version: 3.1.1
  Commit:  a1388f194c

.NET Core SDKs installed:
  2.2.402 [/usr/share/dotnet/sdk]
  3.0.102 [/usr/share/dotnet/sdk]
  3.1.101 [/usr/share/dotnet/sdk]

.NET Core runtimes installed:
  Microsoft.AspNetCore.All 2.2.8 [/usr/share/dotnet/shared/Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.2.8 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.0.2 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.1.1 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 2.2.8 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 3.0.2 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 3.1.1 [/usr/share/dotnet/shared/Microsoft.NETCore.App]

To install additional .NET Core runtimes or SDKs:
  https://aka.ms/dotnet-download

I tried to install Microsoft.Data.SqlClient 1.1.1 and the 2.0.0-preview1.20021.1, but that didn't help.

Please let me know if I can help out by providing more information or trying out different packages.

I have another project running with the same packages on Ubuntu, but without saving or reading data with EF Core, just using EF for migrations, and in that project we don't see any of the above issues.

[cheenamalhotra]

Hi @simonauner

The driver shouldn't be loading sni.dll on Ubuntu in any case 😟
Can you provide us a repro app that we can try? Have you also tried on any other linux machine and do you hit the same problem?

[simonauner]

Hi @cheenamalhotra

Yes, the other machine being the CI machine for Azure Pipelines (I linked the machine specs in my previous post).

I'll try to setup a minimum reproducible repo and get back to you.

[simonauner]

I've tried to setup a basic repo that mimics the failing repo of ours, but everything seems to be working fine. My guess is that something we do in the DBContext setup messes it up. Can't find the issue at the moment though.

[naveedahmed1]

Any update on this? Is there any fix? I am also receiving this error when I deploy my app:

An unhandled exception occurred while processing the request.
DllNotFoundException: Unable to load DLL 'sni.dll' or one of its dependencies: Access is denied. (0x80070005 (E_ACCESSDENIED))
Microsoft.Data.SqlClient.SNINativeMethodWrapper.SNIInitialize(IntPtr pmo)

TypeInitializationException: The type initializer for 'Microsoft.Data.SqlClient.SNILoadHandle' threw an exception.
Microsoft.Data.SqlClient.TdsParserStateObjectFactory.get_EncryptionOptions()

TypeInitializationException: The type initializer for 'Microsoft.Data.SqlClient.TdsParser' threw an exception.
Microsoft.Data.SqlClient.TdsParser..ctor(bool MARS, bool fAsynchronous)

[Shubbi]

I am also getting this error after we upgraded to EFCore 3.1.3 from EFCore 2.x

(on local machines with iis express it is working fine .....only when I deploy it to server it fails)

I've taken following steps so far

Copied the sni.dll from C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App\2.1.16
to the bin\x64 folder where I hosted the service
Installed Microsoft.Data.SqlClient 1.1.1 on the API project
In the web.config added

But no luck so far
Only the exception message changed a little bit.
Previously it was
-Exception: System.TypeInitializationException: The type initializer for 'Microsoft.Data.SqlClient.SNINativeMethodWrapper' threw an exception. ---> System.ComponentModel.Win32Exception: Failed to load d:\webdocs\myapplication\bin\x64\SNI.dll
at Microsoft.Data.SqlClient.SNINativeMethodWrapper..cctor() in E:\agent1_work\34\s\src\Microsoft.Data.SqlClient\netfx\src\Microsoft\Data\Interop\SNINativeMethodWrapper.cs:line 66

Now it is
System.TypeInitializationException: The type initializer for 'Microsoft.Data.SqlClient.SNINativeMethodWrapper' threw an exception. ---> System.ComponentModel.Win32Exception: Failed to load d:\webdocs\esamd\esamservice\bin\x64\SNI.dll ---> System.ComponentModel.Win32Exception: Access is denied

We are having WebAPi project on .Net Fremework 4.7.1 , and the class libraries are .Net Standard 2.0

I also tried to install Microsoft.Data.SqlClient.Sni package even though it said not for direct consumption but that didn't help either

[vanlanckerst]

Anyone able to resolve this issue? Having the same error which is blocking me to deploy my website..

[naveedahmed1]

Only thing that works in my case is #496 (comment)

[vanlanckerst]

Man that's bad.. :/
I asked our hosting provider if they could do the same, but since we're on a shared server..

[naveedahmed1]

If you have ftp access to your hosting account, you can use any ftp client e.g. Filezilla, right click sni.dll file and set File Permissions to 774.

[vanlanckerst]

Thanks a lot that helped!

[mac2000]

Not sure if this belongs here, I'm building small cross platform sql2csv utility everything is ok on mac os but on windows I receive:

Error:
  An assembly specified in the application dependencies manifest (sql2csv.deps.json) was not found:
    package: 'Microsoft.Data.SqlClient.SNI.runtime', version: '2.0.0'
    path: 'runtimes/win-x64/native/Microsoft.Data.SqlClient.SNI.pdb'

builds are made with following flags:

dotnet publish \
    -c Release \
    -p:PublishReadyToRun=true \
    -p:PublishSingleFile=true \
    -p:PublishTrimmed=true \
    --self-contained true \
    -r ${{ matrix.runtime }}

my expectation of PublishReadyToRun and self-contained flags is that nothing will be required (I got 70mb+ artifacts) but still SNI is not included

wondering if there is any known workaround, explicitly installing this library does not give any results, but builds without single file are working ok

[cheenamalhotra]

Hi @mac2000

Please view this issue in Dotnet SDK: dotnet/sdk#10523

[mac2000]

Hello @cheenamalhotra thank you, indeed adding <IncludeSymbolsInSingleFile>true</IncludeSymbolsInSingleFile> did the trick, just leaving this for future references

[GustavoAmerico]

Hello @cheenamalhotra thank you, indeed adding <IncludeSymbolsInSingleFile>true</IncludeSymbolsInSingleFile> did the trick, just leaving this for future references

It's worked for me

[grepspe]

Hello, I have the same problem : migrating a .NET Core project from 2.2 to 3.1 with EF Core - not working because of DLL loading problem.

In my case, the problem is indeed related to the new location of the sni.dll file - the antivirus stuff on my computer (McAfee Endpoint Security, managed by the IT security department) is forbidding any program to load .dll file from my user directory.

You may check if you are in a similar case by looking at your antivirus logs or to the Windows Application logs - in my case, the logged messages are quite explicit.

So now, I have to deal with the IT security department...

[adrianiftode]

We didn't pass this issue with IncludeSymbolsInSingleFile, but after enabling CopyLocalLockFileAssemblies.
<CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies>

The scenario is that we are using EF 3.1 in some AWS Lambda projects and when we want to start the Lambda Mock Test Tool, then we can't because of the OP issue. We get the following message

AWS .NET Core 3.1 Mock Lambda Test Tool (0.10.1)
Unknown error occurred causing process exit: Dependency resolution failed for component D:\...\bin\Debug\netcoreapp3.1\XXXXX.dll with error code -2147450740. Detailed error: Error:
  An assembly specified in the application dependencies manifest (XXXXX.deps.json) was not found:
    package: 'runtime.win-x64.runtime.native.System.Data.SqlClient.sni', version: '4.4.0'
    path: 'runtimes/win-x64/native/sni.dll'

   at System.Runtime.Loader.AssemblyDependencyResolver..ctor(String componentAssemblyPath)
   at Amazon.Lambda.TestTool.Runtime.LambdaAssemblyLoadContext..ctor(String lambdaPath) in C:\codebuild\tmp\output\src782171135\src\Tools\LambdaTestTool\src\Amazon.Lambda.TestTool\Runtime\LambdaAssemblyLoadContext.cs:line 28
   at Amazon.Lambda.TestTool.Runtime.LocalLambdaRuntime.Initialize(String directory, IAWSService awsService) in C:\codebuild\tmp\output\src782171135\src\Tools\LambdaTestTool\src\Amazon.Lambda.TestTool\Runtime\LocalLambdaRuntime.cs:line 71
   at Amazon.Lambda.TestTool.Runtime.LocalLambdaRuntime.Initialize(String directory) in C:\codebuild\tmp\output\src782171135\src\Tools\LambdaTestTool\src\Amazon.Lambda.TestTool\Runtime\LocalLambdaRuntime.cs:line 46
   at Amazon.Lambda.TestTool.TestToolStartup.Startup(String productName, Action`2 uiStartup, String[] args, RunConfiguration runConfiguration) in C:\codebuild\tmp\output\src782171135\src\Tools\LambdaTestTool\src\Amazon.Lambda.TestTool\TestToolStartup.cs:line 77

[RomBrz]

After some time trying to figure out how to solve this and another potential problems, i would like to share what solved for me:
(I posted that too on dotnet/sdk#7480)

I've tried to find something related to this officially, and seems like Microsoft tell us to use Read and Execute by default:

"Read & execute permissions should be granted by default"

https://docs.microsoft.com/en-us/aspnet/core/host-and-deploy/iis/?view=aspnetcore-3.1

With that, we changed the procedures to host DotNet Core applications, changing every project to use Read And Execute instead of Read, and with that the sni.dll (and other DLL) should not be a problem.

Personally i don't agree with this "default" as i told early; Execute permission could give security problems, and DotNet Framework seems to work fine with Read only, but i cannot argue with official documentation...

[cheenamalhotra]

Closing issue as this is no-op for us.

[JesseKPhillips]

My issue was that I was building for Windows and not Linux

• OLD: dotnet publish -r win-x64 --self-contained false
• NEW: dotnet publish -r linux-x64 --self-contained false

Probably related:

• Failed to load sni.dll runtime#23323
• Unable to load shared library 'Microsoft.Data.SqlClient.SNI.dll' in Ubuntu 18.04 #742