1

After some help and reading, I am sure the concept activation context can be used to solve my problem. In my application, I have to load an unmanaged dll c.dll by another managed dll b.dll, which is loaded by a.dll, which is loaded by app.exe. The sequence is that

app.exe -> a.dll (managed) -> b.dll (managed) -> c.dll (unmanaged)

I have the source of a.dll and b.dll, but app.exe and c.dll belongs to the third party. Now, regardless of whether a.exe loads other versions of c.dll or not, I have to load my own c.dll (my c.dll resides in a different folder with that carried by a.exe installation).

I used LoadLibraryEx, but that app.exe have loaded a different of c.dll before I can load my own c.dll. These two c.dll are same name with different versions. Since a different version of c.dll has been loaded, when I called LoadLibraryEx, my c.dll won't be loaded. I need a solution to solve this problem.

How does the concept activation context can be migrated to the .NET environment to solve this problem?

StayOnTarget
  • 11,743
  • 10
  • 52
  • 81
Lucas
  • 222
  • 3
  • 9

1 Answers1

0

I'm not sure what you mean by activation context.

If you want to load an unmanaged DLL in a managed environment you need to do so via pInvoke:

[DllImport("kernel32", SetLastError=true, CharSet = CharSet.Ansi)]
static extern IntPtr LoadLibrary([MarshalAs(UnmanagedType.LPStr)]string lpFileName);

Also, you will need to free the handle stored in the IntPtr returned by LoadLibrary.

Kieran Foot
  • 706
  • 5
  • 11
  • yes, I used `LoadLibraryEx`, but that `app.exe` have loaded a different of `c.dll` before I can load my own `c.dll`. These two `c.dll` are same name with different versions. Since a different version of `c.dll` has been loaded, when I called `LoadLibraryEx`, my `c.dll` won't be loaded. I need a solution to solve this problem. – Lucas May 26 '22 at 08:41
  • `LoadLibraryEx` takes the path of the dll as a parameter so the handle returned should be to that particolar version identified by the path. You can load as amny dll versions as you want using different paths – Marco Beninca May 26 '22 at 13:10
  • @MarcoBeninca No, bro. you are wrong. you can write the codes and see the result. If you have loaded `a.dll` by `LoadLibraryEx`, it will return `NULL` if you attempt to load another different version but same name `a.dll` by calling `LoadLibraryEx` again. – Lucas May 26 '22 at 16:13
  • @Lucas the solution is to use the old version then I guess... – Kieran Foot May 26 '22 at 21:17
  • `LoadLibrary` cannot load the same name dll. I tried, If 1. GetCurrentDirectory 2. SetCurrentDirectory(path1) 3, m1 = LoadLibary(libcef.dll) 4, setcurrentdirectory(path2) 5, m2 = LoadLibrary(libcef.dll) 6. restore the old current path for this process. m1 equals m2 – Lucas May 27 '22 at 00:51
  • @Lucas a more complicated solution but maybe defenetive could be to write different applications wchich then can communicate via a WCF service... this way any app is responsible to load a specific version of the dll – Marco Beninca May 27 '22 at 06:25
  • 1
    @MarcoBeninca yes, this idea is what I am thinking. the out-of-process model is useful in this problem. Createing a helper process, using that process to load my library, then communicate by some IPC mechanism. – Lucas May 27 '22 at 09:38