System.DllNotFoundException: Unable to load DLL 'libsodium'

[e-davidson]

I noticed the libsodium runtime dll was removed from the latest nuget package.
Is that the issue?

[tabrath]

I know, its broken atm. Will try to fix it soon.

[rwasef1830]

It is because of dotnet/sdk#1479

To fix it, add the runtimes manually like this:

  <ItemGroup>
    <None Include="runtimes\win7-x86\native\**\*">
      <PackagePath>runtimes/win7-x86/native/</PackagePath>
      <Pack>true</Pack>
    </None>
    <None Include="runtimes\win7-x64\native\**\*">
      <PackagePath>runtimes/win7-x64/native/</PackagePath>
      <Pack>true</Pack>
    </None>
  </ItemGroup>
  
  <ItemGroup Condition="'$(TargetFramework)' != 'net461'">
    <None Include="runtimes\osx-x64\native\**\*">
      <PackagePath>runtimes/osx-x64/native/</PackagePath>
      <Pack>true</Pack>
    </None>
    <None Include="runtimes\linux-x64\native\**\*">
      <PackagePath>runtimes/linux-x64/native/</PackagePath>
      <Pack>true</Pack>
    </None>
  </ItemGroup>

The difference is None Include vs None Update (due to the sdk bug, the default auto inclusion is not working when project is multi-targeted).

[tabrath]

@rwasef1830 Want to add a PR for that?

[rwasef1830]

Sure, got many things to improve in this library. I will make a bunch of PRs soon. This is the only good library that brings libsodium to .NET Core (and VS2017) and it needs a lot of love.

[rwasef1830]

@tabrath there's a little snag, in order for the unit tests project to work properly, we will have to split the project into 2 nuget packages, one which has only the native libsodium runtimes (and nothing else) (we can take the time to update to libsodium 1.0.13 while at it), so that it can be added as a PackageReference to the unit tests project so that the libsodium.dll is copied to the bin of the unit test project.

(Note: It seems it was working before by pure luck, if you had python installed and added to path, it was finding python's libsodium.dll from path and loading that, masking the problem, but it's kind of dangerous, similar to a reverse dll preload attack, verify with process monitor).

This mess is due to dotnet/sdk#765 which won't be fixed soon.
ASP.net Core have done the same thing with https://www.nuget.org/packages/Libuv/ (it only contains native runtimes and no C# code) and put all the related C# code in another package.

I suggest a new NuGet package (libsodium), but it seems @jedisct1 was already trying the same thing with https://www.nuget.org/packages/libsodium/1.0.12-preview-01

We could depend on that package directly instead but it is marked as preview which is kinda ugly. Or we can make our own 'Sodium.Core.Native' NuGet or something.

What do you think ?

[tabrath]

@rwasef1830 Good thing you catched that bug! I've been thinking about the same thing, a pure native package, seems to be the cleanest (and best?) way since the dotnet team is doing the same. As for the package name; that sounds good to me. Btw, seems there's an ongoing effort to get this working by the team behind libsodium here..

[rwasef1830]

@tabrath then in that case, I think we should depend directly on the existing libsodium package since it will let users update the native libsodium without having to wait for a new release for this library (as long as API compatibility is not broken).

[tabrath]

@rwasef1830 Lets give them a couple of days and see how it goes, shall we?

[rwasef1830]

This should be fixed now.

[tabrath]

Thanks alot.

[dtanders]

I just tried using Libsodium.Core today in a brand new project targeting 4.6.2 in VS2017 and it's not copying the native libsodium.dll, so I think you closed this prematurely. Or am I missing something?

[tabrath]

@dtanders Are you target any specific architecture? Try targeting either x64 or x86..

[dtanders]

Targeting an architecture didn't do anything.

https://drive.google.com/open?id=16gCpD1a4c4HT1kaaofFKvvEy8DPkTJBT is the project if you want to try to reproduce the issue.

[tabrath]

@dtanders Well, first off; Sodium.Core is mainly for .NET Core. I tried your project and I could not get it to work using our library. But, using libsodium-net it works like a charm, well .. kind of. For some weird reason it did not install it's dependency of Baseclass.Contrib.Nuget.Output which takes care of copying the native libraries to your output folder. I installed it manually and it worked. When libsodium-net releases their new version, this library will be deprecated.

[dtanders]

Baseclass.Contrib.Nuget.Output was trying to reference a VS tooling DLL that doesn't exist, which is why I tried .Core. I see that they fixed it, so I'll stop bothering you guys... and start bugging the -net people because their wrapper still can't find the DLLs that are at least copying to bin correctly now :|

E: I nuked the project and re-created it and now it works. 🎵Just NuGet things🎵 I guess

[tabrath]

Great thing you got it working in the end! Don't worry bothering us, feedback is always welcome. Its such a shame the inclusion of native libraries often is problematic, hopefully core will change that.