G
Guest
Background:
We have developed an C# MDI (Multi-Document Interface) application which
loads different assemblies/forms, so that the user can have many "application
windows" running within the same container. Some of these child forms need
to use legacy code from a mature product written in C, and we have achieved
this by compiling our C code into a DLL, and using DllImport directive to
reference the functions that we need. The C# applications are able to use
the functions perfectly, but we are now facing another challenge.
The Challenge:
The C code uses caching to reduce database access delays, and those caches
are simple linked lists or arrays that are global/static. While this
assumption worked well for our legacy application (which is comprised of
numerous stand alone executables that naturally have their own process
space), it doesn't work well for the MDI C# model. That is, two child forms
running inside the MDI would share those caches, since all the
assemblies/forms (and DLLs) share the same process space. However, for our
product, it is unacceptable for two MDI child forms to share the same data
cache (for example, the cached data may have been derived based on user
preferences that are specific to each child form).
Where We're Stuck:
We have been trying to load the DLL more than once into the MDI process
space, where each copy will have it's own static/global variables, and
therefore different cached data, but we were unsuccessful. We attempted
loading them through different Application Domains, but it looks like the
external reference is resolved only once per DLL and reused (i.e. all app
domains reference the same copy of the DLL in the MDI process space).
Of course, we could rewrite the C code to eliminate the global/static memory
assumptions, but this isn't feasible due to the amount/complexity of the
legacy code.
We've also considered managing multiple copies of the dll to overcome this
problem (we've tested this and it works), but we don't want to resort to a
hack like this unless we have no other choice.
The Question:
Does anybody know of a way to load multiple instances of the same unmanaged
C++ dll into the process space of a single C# application (using application
domains or some other technique)?
We have developed an C# MDI (Multi-Document Interface) application which
loads different assemblies/forms, so that the user can have many "application
windows" running within the same container. Some of these child forms need
to use legacy code from a mature product written in C, and we have achieved
this by compiling our C code into a DLL, and using DllImport directive to
reference the functions that we need. The C# applications are able to use
the functions perfectly, but we are now facing another challenge.
The Challenge:
The C code uses caching to reduce database access delays, and those caches
are simple linked lists or arrays that are global/static. While this
assumption worked well for our legacy application (which is comprised of
numerous stand alone executables that naturally have their own process
space), it doesn't work well for the MDI C# model. That is, two child forms
running inside the MDI would share those caches, since all the
assemblies/forms (and DLLs) share the same process space. However, for our
product, it is unacceptable for two MDI child forms to share the same data
cache (for example, the cached data may have been derived based on user
preferences that are specific to each child form).
Where We're Stuck:
We have been trying to load the DLL more than once into the MDI process
space, where each copy will have it's own static/global variables, and
therefore different cached data, but we were unsuccessful. We attempted
loading them through different Application Domains, but it looks like the
external reference is resolved only once per DLL and reused (i.e. all app
domains reference the same copy of the DLL in the MDI process space).
Of course, we could rewrite the C code to eliminate the global/static memory
assumptions, but this isn't feasible due to the amount/complexity of the
legacy code.
We've also considered managing multiple copies of the dll to overcome this
problem (we've tested this and it works), but we don't want to resort to a
hack like this unless we have no other choice.
The Question:
Does anybody know of a way to load multiple instances of the same unmanaged
C++ dll into the process space of a single C# application (using application
domains or some other technique)?