libsodium-net icon indicating copy to clipboard operation
libsodium-net copied to clipboard

0.10.0-beta3 keeping libsodium-64.dll locked

Open grumpydev opened this issue 8 years ago • 2 comments

I'm using the latest beta and using these two methods in an ASP.Net app, currently hosting in IIS Express:

PasswordHash.ArgonGenerateSalt PasswordHash.ArgonHashBinary

The code itself is working fine, but once I've called those methods once the libsodium-64.dll seems to remain locked forever, so any attempt at rebuilding the solution fails because it can't copy the file - in order to do a build I have to kill IISExpress each time.

Is this expected behaviour or an issue with the beta? I'm only using statics so I'm assuming its not because I'm leaving something un-disposed?

grumpydev avatar Aug 18 '16 14:08 grumpydev

I am seeing this in the nuget version as well, when running unit tests. There's a workaround in the unit testing scenario because you can tell Visual Studio to get rid of the execution process each time. I suspect it is to do with the all the static LazyInvoke objects in SodiumLibrary, they must be keeping a handle to the dll open. SciTech's .NET Memory Profiler (memprofiler.com) is a great tool for getting to the bottom of this sort of thing.

guysherman avatar Oct 31 '16 11:10 guysherman

+1 happening here with xunit unit tests. Test execution engine keeps lock on libsodium.dll. Subsequent project rebuilds then fail because they cannot overwrite this file. This is with v0.10.0 final, not beta3.

mdsharpe avatar Feb 27 '17 14:02 mdsharpe