1

Our app (C# WPF) is using some C++ libraries, and I'm trying to make it so that the dll could be replaced with a different version on app startup.

Simply replacing the file at startup, before it was referenced, worked, but it's not quite what I needed.

Then I tried to replace it while it's in use, i.e. renaming the current file, copying a new one under the original name – this way during the next startup a new version would be used. That does seem to work, but my question is – how reliable is it? From my testing, it seems that the file lock does allow renaming, but is it always the case? I don't wanna find out down the road that sometimes the lock is different and this doesn't work at all Sadly, I could not find anything in the MS documentation about this.

Of course an alternative (arguably the best way to go) would be LoadLibrary instead of DllImport, but that would require rewriting the wrapper and reloading during runtime is not really needed.

Domas
  • 139
  • 3
  • 9
  • [Related](https://stackoverflow.com/questions/2445536/unload-a-dll-loaded-using-dllimport) – ProgrammingLlama Oct 11 '22 at 06:28
  • 1
    The CLR already uses LoadLibrary() so using it yourself doesn't get you ahead. The OS loader uses a memory-mapped file to map the DLL content into memory. That puts a lock on the file that is equivalent to FileShare.None in C# code. Yes, that does not prevent renaming, other than the user's security software stepping in. But that does not accomplish anything, the OS continues to use the renamed file content. Only when you restart the program does a replacement get used. The security software issue voids any warranty you could get here. – Hans Passant Oct 11 '22 at 06:38
  • My thoughts are that naming the new file something like mylibrary.dll.new (where the old one is mylibrary.dll) and then restarting your program with some code to detect the .new file and swap it out might be the most sensible solution. – ProgrammingLlama Oct 11 '22 at 06:41
  • @HansPassant yes, I meant that using LoadLibrary would give more control and allow to unload & reload it again Didn't think about any issues with security software, I wonder how likely is that – Domas Oct 11 '22 at 06:47
  • "Didn't think about any issues with security software, I wonder how likely is that" Very. Your app sounds like malware. You might not think so, but the security software's opinion is the one that counts. Are you trying to write an updater program? – David Heffernan Oct 11 '22 at 09:42
  • @DavidHeffernan The idea is to ship multiple versions of some c++ dlls (let's say Beta & Stable) and have the ability to switch them up base on a feature flag. Renaming & having the new version used on the next app start should work fine if no security software were to intervene. – Domas Oct 12 '22 at 06:26
  • 1
    Well that sounds weird to me. I'd just load different dlls and not try to copy files around. Give the files the same names and put them in different folders. Then use DllImport with just the dll name. And before you call a function use LoadLibrary to load the DLLs by full path. Then the subsequent calls to DllImport functions will use the already loaded DLL. – David Heffernan Oct 12 '22 at 10:40
  • Woah, did not know that, I just assumed each of them would load the same dll again (kind of like different instances of the same object). Thanks. – Domas Oct 12 '22 at 13:45

0 Answers0