Throwing 'dll not found' exception when using in .NET Core 2.0 Console app.

[tom-auger]

A quick fix is to manually copy the Zstandard.Net.dll into your build output folder. The dll will reside in your local nuget cache, most likely in ~\.nuget\packages\zstandard.net\1.1.2\lib\netstandard2.0\.

Zstandard.Net.dll searches for libzstd.dll relative to it's current location. When compiling a .NET core application for debugging dotnet build doesn't copy package reference dlls to the output folder. When you run your application, since Zstandard.Net.dll is not present in the working directory, it looks for it in your local nuget stores. However the contents of \lib\netstandard2.0\ within the nuget package doesn't contain the libzstd.dll files (which are instead located in \build\), hence the dll not found exception.

[coding-komek]

I'm also having this problem with a .NET Framework 4.6.1 Web Application. Since copying the file manually is not an option for the deployment process, the file should be copied to and found properly within the output folder.

The libzstd.dll file always gets copied to %outputfolder%/x64 (and x86 respectively), but is not found when compiling with 'Any CPU'. Compiling in this mode leads to the OSVersion.Platform being "Win32S", which does not pass the check in the static constructor of "ZstandardInterop.cs". Setting the compiler to x64 fixes the problem, as the Platform is now the desired "Win32NT" but we do not want to restrict our application to x64 only.

I think the check could be removed, so if the dll could not be loaded for the application, we will at least get an error message saying so.

[bp74]

Hi, thanks for the feedback. I think we should add "Win32S" as a valid windows platform to the code. The platform check is necessary to make the library work on Linux. On Linux the loading of the windows DLL makes no sense.

[jjxtra]

I would vote that the Windows, Linux and MAC versions of the zstdlib be embedded resources. They can be extracted and written to the appropriate path if needed in the static constructor of the interop class.

[bp74]

Yes sounds like a good idea but can't be done. You can only load a native Windows DLL from a file path, but many applications don't have the right to write a file (e.g. a web application). I don't know how it works on Linux but i expect it is the same. Additionally you have to embed lot's of native code to make it work on all platforms.

[vbelot]

A better solution would be to adopt the recommended structure for native library loading, which should now be found under the "runtimes" folder.