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!

> 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]

Hi Gunter

Thank you for the quick reply. You confirmed our suspicion.
We actually use the LoadLibrary approach for a few DLLs, and this works
because those DLLs have a very limited C style API - it would not work with
what I have at hand here.
The architecture suggesting the use of a single process hosting multiple
AppDomains is meant to address load balancing issues, and better utilization
of resources. I have no control over this decision.
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.

To illustrate:

Assuming we are working on version 1.1
I build NativeDLL.dll (V 1.1).
I copy the result so I have NativeDLLForAppA.dll (V 1.1) and
NativeDLLForAppB.dll (V 1.1).

Then I build MyAssembly.dll that links with NativeDLLForAppA.dll, and
another MyAssembly.dll that links with NativeDLLForAppB.dll.

This is done per version.

Now Assume I have released V1.1 and V1.2. And both versions are to be
consumed in different AppDomains in the same process.
The assemblies will not be a problem – as the code is managed – the exact
reference will be loaded.
The native DLLs will not be a problem, as each app uses an assembly that
links with a distinct (renamed) set of DLLs.

Not very nice – but should do the trick in lack of a better solution.

Adam

[Rich Lander [MSFT]]

> 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]]

"Rich Lander [MSFT]" <ri...@lander.ca> wrote in message
news:e6746d52-2495-49db...@n2g2000vba.googlegroups.com...

>> 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).

>
> 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]]

"Rich Lander [MSFT]" <ri...@lander.ca> wrote in message
news:e6746d52-2495-49db...@n2g2000vba.googlegroups.com...

>> 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.