1
I'm working with a set of experiments in a large system that is using AppDomains for isolation and wants to make a call out to an umanaged dll. The test dll has two methods, SetNumber(int num) and GetNumber(), and a global variable. The DllImport and getting and setting the numbers are fine.
The problem comes when I make the calls to the libraries from separate AppDomains. Calling SetNumber with 3 different values across 3 different AppDomains gives me the same value when I call GetNumber() on those domains. The .dll holds it values and behaves as a singleton implementation. Unfortunately, this isn't what we wanted!
Is there any way to get a legacy dll to run with a unique instance inside each AppDomain?
Some more information: in my struggles, I've found that there are 3 pretty decent ways to load Legacy dlls:
1) DllImport - The standard way to load DLL's specified at compile time.
2) LoadAssembly - along with GetProcAddress and FreeLibrary can load dlls on the fly. Note: You need a bit of hefty code to use the proc address in C#, code that declares a delegate and a struct and the Marshal class.
3) DynamicAssembly - I like this one the best: Allows you to load assemblies on the fly by creating a new assembly in the appdomain and pinvoking on that. Easily understandable if you have experience with reflection, usually.
Unfortunately all of these methods load up the DLL inside the main process and only once for this process. Any calls to that DLL from any AppDomains seem to be going to the very same DLL that was loaded into the overall process. Again, this is the behavior we're trying to kill, so does anyone have any ideas at all?
