How do I get rid of SNI.dll when publishing as a "single file" in Visual Studio 2019?

user_9393918 0
Viewed 2170

I'm trying to publish a very simple C# .Net 5.0 WinForms application (single file output) as a test case for porting from the .Net Framework v4.6.1 (what it was previously) while using Visual Studio 2019 v16.8.2. The Publish options are as follows:

  • Configuration: Release | Any CPU
  • Target Framework: net5.0-windows
  • Deployment Mode: Framework-dependent
  • Target-Runtime: win-x64
  • Produce Single File: Enabled
  • Enable ReadyToRun Compilation: Disabled

Although the build works fine and merges the two source assemblies into a single output executable, it also includes SNI.dll in the output directory. The application will not start without this DLL in the same folder as the executable so my question is: How do I remove the dependency on SNI.dll so it does not get included with the published executable and is not required to run?

The application is a simple front-end to generate random data using the Crypto-API. It does not include any database functionality whatsoever, which is why it's so confusing to me that SNI.dll is included in the output. As far as I can tell, SNI.dll is related to Microsoft.Data.SqlClient, which I don't use

Any help with this would be most appreciated. Cheers

PS. I should mention, all my attempts to Google this fault have turned up articles about "SNI.dll Missing", "SNI.dll failed to load" or some other variant of that

publish winforms .net
2 Answers

I faced the same problem as yours and found the solution here. It turns out that native libraries are not bundled in the single file executable by default. You must set the flag IncludeNativeLibrariesForSelfExtract to true to get this behavior.

You might also want to check your .deps.json file (from your build folder) to see how you got this dependency in the first place.

user_16424270

As Simon V. stated, you can work around this issue by adding IncludeNativeLibrariesForSelfExtract to your project file and setting it to true.

tl;dr Dotnet's Windows runtime depends on sni.dll.

One day I hope to find out why it's there at all since I can't even find a reference to System.Data anywhere in my entire solution, but you've been a big help. Cheers

-- HumanBean

You might also want to check your .deps.json file (from your build folder) to see how you got this dependency in the first place.

-- Simon V.

Given a publish directory path of "bin\Release\net6.0-windows\win-x86\publish", check in the parent directory (win-x86, the RID) for a file named "$(AssemblyName).deps.json".

Search that folder for a dependency's assembly name or file name.

In my project's dependencies file, "sni.dll" is referenced by the following snippet:

{
  "runtimeTarget": {
    "name": ".NETCoreApp,Version=v6.0/win-x86",
    "signature": ""
  },
  "compilationOptions": {},
  "targets": {
    ".NETCoreApp,Version=v6.0": {},
    ".NETCoreApp,Version=v6.0/win-x86": {
      ...
      "runtime.win-x86.runtime.native.System.Data.SqlClient.sni/4.4.0": {
        "native": {
          "runtimes/win-x86/native/sni.dll": {
            "fileVersion": "4.6.25512.1"
          }
        }
      },
      ...
    }
  }
}

For the sake of further investigation, I'll include additional information.

All instances of sni.dll on my computers share the following attributes...

  • ProductVersion: 4.6.25512.01 built by: dlab-DDVSOWINAGE016. Commit Hash: d0d5c7b49271cadb6d97de26d8e623e98abdc8db
  • ProductName: Microsoft® .NET Framework
  • Modified Date: 7/12/2017.

I wonder why the .NET 5+ runtimes depend on what appears to be a component of the .NET Framework.

user_148947860
Related