none
AppDomains, Legacy Code, and DllImport

    Question

  • 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?
    Friday, October 12, 2007 3:48 PM

Answers

  • The bad news is that you only have one process and can't isolate unmanaged code in that way.  Unmanaged code is effective global to all AppDomains.

     

    One possible work around is to protect the calls with a named Mutex.  Another is to create external processes for each AppDomain and use inter-proces communication to call into your native dlls.

    Friday, October 12, 2007 10:18 PM

All replies

  • No one yet?

    Well 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?
    Friday, October 12, 2007 8:52 PM
  • The bad news is that you only have one process and can't isolate unmanaged code in that way.  Unmanaged code is effective global to all AppDomains.

     

    One possible work around is to protect the calls with a named Mutex.  Another is to create external processes for each AppDomain and use inter-proces communication to call into your native dlls.

    Friday, October 12, 2007 10:18 PM
  •  Josh.Cooley wrote:

    The bad news is that you only have one process and can't isolate unmanaged code in that way.  Unmanaged code is effective global to all AppDomains.

     

    One possible work around is to protect the calls with a named Mutex.  Another is to create external processes for each AppDomain and use inter-proces communication to call into your native dlls.



    thanks for confirming. This is in line with what i've found. Shame, that. The memory savings from AppDomains are pretty nice, but I guess that sacrifices could be made.
    Monday, October 15, 2007 2:44 PM