AppDomains and native DLLs

[Adam]

A development team I work with distributes a .NET assembly (implemented in
MC++) that in turn depends on native DLLs.
This assembly is consumed by a few teams that develop servers that perform
some business that depends on this assembly.
These applicative teams now wish to run their applications in a single
process by creating several appdomains.
The catch is that the various applications depend on different versions of
this same assembly, and thus on different versions of the native DLLs.
From initial tests we performed we know that the first appdomain to call our
assembly will get its version of the native DLLs loaded. When the second
appdomain loads our assembly (but a different version), it will load the
second version of the managed assembly, but will use the native DLLs already
loaded for the first appdomain (which may not be compatible with the assembly
loaded by the second appdomain).
Is there any way around this? For example, can I create a multi file
assembly referencing the native DLLs, so that each appdoain gets its own
version?
If yes – how? If not, any other ideas?

Thanks
Adam

[Günter Prossliner]

Hallo Adam!

Post by Adam
The catch is that the various applications depend on different
versions of this same assembly, and thus on different versions of the
native DLLs.

Sorry, but you will not succeed this way.

An unmanaged module knowns nothing about AppDomains. The boundaries or
unmanaged Code still is at process-level, regardless if there are loaded
managed modules or if the Process has been started by an managed exe.

With LoadLibrary / GetProcAddress (eg. by providing different names for each
version), it may be possible, but I won't recommend it to you.

You may use different processes instead of AppDomains.


GP

[Adam]

This post might be inappropriate. Click to display it.

[Rich Lander [MSFT]]

Post by Adam
My backup plan is to deliver several sets of native DLLs - renamed according
to the appropriate client applications - I will create them by copying – so
they are exactly identiicle. Then I will build several versions of my
assembly, by linking with a different set of renamed DLLs. Thus the client
will be able to use multiple versions of the same native DLL, as each
assembly will link with a version of the native DLL with a different name.

If the dlls are identical, then you should be able to re-use the same
copy across ADs. If they are not identical, then adding the version
number in the name of the file makes sense.

You also want to make sure that your native dlls do not depend on any
process-global resources, or else your native dlls may conflict with
each other.

thanks -- rich

[Ben Voigt [C++ MVP]]

Post by Rich Lander [MSFT]

Post by Adam
My backup plan is to deliver several sets of native DLLs - renamed according
to the appropriate client applications - I will create them by copying – so
they are exactly identiicle. Then I will build several versions of my
assembly, by linking with a different set of renamed DLLs. Thus the client
will be able to use multiple versions of the same native DLL, as each
assembly will link with a version of the native DLL with a different name.

If the dlls are identical, then you should be able to re-use the same
copy across ADs. If they are not identical, then adding the version
number in the name of the file makes sense.
You also want to make sure that your native dlls do not depend on any
process-global resources, or else your native dlls may conflict with
each other.

And if the DLLs import another DLL that uses global data, you'll still end
up with data sharing across app-domains no matter what you do (short of
recompiling all dependencies with /clr and app-domain awareness).

Post by Rich Lander [MSFT]
thanks -- rich
__________ Information from ESET NOD32 Antivirus, version of virus
signature database 4512 (20091015) __________
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com

__________ Information from ESET NOD32 Antivirus, version of virus signature database 4512 (20091015) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

[Ben Voigt [C++ MVP]]

Post by Rich Lander [MSFT]

Post by Adam
My backup plan is to deliver several sets of native DLLs - renamed according
to the appropriate client applications - I will create them by copying – so
they are exactly identiicle. Then I will build several versions of my
assembly, by linking with a different set of renamed DLLs. Thus the client
will be able to use multiple versions of the same native DLL, as each
assembly will link with a version of the native DLL with a different name.

If the dlls are identical, then you should be able to re-use the same
copy across ADs. If they are not identical, then adding the version
number in the name of the file makes sense.
You also want to make sure that your native dlls do not depend on any
process-global resources, or else your native dlls may conflict with
each other.

oh gee, you already said what I did.... I was thinking of your statement in
terms of named kernel objects, but those are session-global, not
process-global.

Post by Rich Lander [MSFT]
thanks -- rich
__________ Information from ESET NOD32 Antivirus, version of virus
signature database 4512 (20091015) __________
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com

__________ Information from ESET NOD32 Antivirus, version of virus signature database 4512 (20091015) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com