Consuming COM-Objects built as .NET assembly

[Markus Eßmayr]

Hello!
As we use .NET technology to build our applications, we also create several
components using it.
To be able to use the components in unmanaged applications, we expose the
public interfaces to COM.

On my workstation, I have .NET 1.0, 1.1 and 2.0 installed.
We now found out, that the .NET runtime always loads the latest version of
itself, if any .NET based COM object is created.

We know, that there are ways to force the loader to use a specific version
of the runtime, but the following topic is not completely clear:

Somebody offers a COM object developed using .NET technology and builds that
using one of the available runtime versions (lets say 2.0).
Another guy, offering another COM object builds that using version 1.1.
A third guy builds an unmanaged application using both COM objects.
Lets say, the application has two functions, A (using COM object 1) and B
(using COM object 2).
If the user activates A before B, COM object 1 gets created first, and
runtime version 2.0 gets loaded into the process. So, COM object 2 will be
executed with runtime version 2.0 too.
If the user does it the opposite way, COM object 1 will be run with runtime
version 1.1.

Thats the way I think it would be!
I know that the best way is to ensure, that all used COM objects are built
with the same runtime version, but what if you don't have a way to do that!?
(if they are developed by external companies)
Use out-of-process COM servers?

Any suggestions!

Thanks, Max

 

[Mattias Sjögren]

Markus,

We now found out, that the .NET runtime always loads the latest version of
itself, if any .NET based COM object is created.

Correct, unless you configure the application to load a specific
version.

If the user activates A before B, COM object 1 gets created first, and
runtime version 2.0 gets loaded into the process. So, COM object 2 will be
executed with runtime version 2.0 too.
If the user does it the opposite way, COM object 1 will be run with runtime
version 1.1.

No as you wrote yourself, the latest version (2.0) will be loaded in
both cases. The code built for the 2.0 runtime wouldn't even load
under 1.1, you'd get an exception.


Mattias

 

[Markus Eßmayr]

Mattias,

thanks for your answer.
I just read my first posting again, and ... you're completely right, the
paragraph with A and B was not correct, because i didn't write the
following:

We found a way to preload the correct runtime for the COMponent using the
"CorBindToRuntimeEx" function. With a preceding call to the "GetFileVersion"
function of the "mscoree.dll", we are able to get the compilation runtime
version, which we preload.
With that as a base, the A and B example makes more sense now!

But theres still no way to solve the
COMponents-using-different-runtime-version-problem.
And I guess, that there will never be one!?

But one thing would still be very interesting for me:
Is there a way to use COMponents out-of-process (using
ActivationOption.Server), and force the .NET runtime to use the
compilation-version of the assembly automatically?

Thanks in advance!

Max