libsodium-net
libsodium-net copied to clipboard
adamcaudill
Put the unmanaged dll's in an EmbeddedResource
Put the unmanaged dll's in an EmbeddedResource and extract them to the dll's Location on startup, so the unmanaged dll's also work with shadow copying (e.g. ASP.NET).
Hi! When would you be able to pull this change into the master? We have run into problems with this issue and we would not like to do dirty workaround for this since the fix seems to be on it's way. Thanks!
Hi, I use my fork in MSPControl. I've had shadow copying issues, like not beeing able to build etc. when the site was running. My fork fixed all that issues. One might argue, more disk space is used, since the EmbededResource needs to be copied on disk. But that's about the only drawback, and maybe the delay for copying. But if you want to support shadow coyping in ASP.NET I don't see any other way, and if you don't you'll always run into problems with build etc. Maybe another solution could be to have the unmanaged dll on disk and to copy to the shadow copy location BEFORE loading it, and loading it from there. That way there's only more disk space used when shadow copying is used, not otherwise. Copying might also be faster than extracting from embedded resource.
It's a nice idea, but there may be one or two issues. The SaveUnmanagedDlls() method uses Assembly.GetExecutingAssembly() which can return unexpected results (see this stack overflow post for example). In my experience AppDomain.CurrentDomain.BaseDirectory tends to be produce more predictable results across project types (i.e. asp.net, forms, wpf, console, services etc.)
The other issue I wonder if anyone might run into is trying to deploy their application into a directory to which the user executing the binary does not have WRITE access?
Lastly, the catch { } on line 65 that this commit would add to libsodium-net/SodiumCore.cs makes me nervous.
If you accept this change, perhaps it first ought to be modified such that users may optionally call an extract method in libsodium which accepts a path parameter to extract the DLLs rather than making assumptions and suppressing exceptions?
I think there's a big difference between AppDomain.CurrentDomain.BaseDirectory and Assembly.GetExecutingAssembly().Location. Location is the path to the shadow copy, whereas BaseDirectory would probably be the Assembly.GetExecutingAssembly().CodeBase, i.e. in the case of ASP.NET the ~/bin directory or am I wrong? I don't know, could be that the user is always allowed to write to the shadow copy folders, since the process running needs to copy all dll's there, in the case shadow copy is enabled no? But, in the case, there is no shadow copying, then it would need to write to the folder where the dll is located originally, and to that folder the process might not be allowed to write, that's correct, and it might fail.
An alternative solution would be to have the unmanaged dll in the correct place, and if shadow copying is enabled to move it to the shadow folder and delete it in the original folder, before loading it. Or, maybe there isn't even the need to delete it, maybe if you'd just copy it to the shadow folder, it'd be loaded from there. This should always work, since the process should always be allowed to write to the shadow copy folder. I don't have time to implement this, but it should be straightforward.
If https://github.com/BurningEnlightenment/libsodium-net/issues/2#issuecomment-304209009 passes, this can be closed, right?
