I have a managed application compiled on .net 1.1 calling a unmanaged ACtive
X control which in turn uses a managed extension C++ COM dll compiled on .
Net 2.0. This causes the following exception to be generated in the managed
app
System.IO.FileLoadException
Common Language Runtime Internal error: 0x80131107
This results due to the a lower version CLR version already loaded in to the
managed applciations process. This situation can be rectified by changing
the application configuration file (supportedRuntime element) to specify
that the 2.0 .Net framework CLR should be loaded. The problem is that the
Active X control is used by many other applications and it is not feasible
to update the app config file each time the Active X control is moved to a
higher version of the framework. Is there any way to specify which version
of a managed COM component should be loaded for a particular version of the
CLR. Any other solution to this problem.
Prasen
Willy Denoyette [MVP] - 01 Apr 2006 20:55 GMT
The problem has nothing to do with the AX control, by default your
application will load the version of the CLR that it was build against
(v1.1), but your ME C++ DLL was built with V2 which means it requires V2 of
the CLR. So you always need the config file supportedRuntime element
specifying V2.
Willy.
|I have a managed application compiled on .net 1.1 calling a unmanaged ACtive
| X control which in turn uses a managed extension C++ COM dll compiled on .
[quoted text clipped - 16 lines]
|
| Prasen
PRASENJIT BURMAN - 04 Apr 2006 15:11 GMT
Is it possible to resolve this problem using the concept of side-by-side
assemblies?
Wherein each application (using the COM comps) will have an application
manifest listing the appropriate version and name of both the dependent
native COM and managed COM component.
The native COM and managed COM component can be installed as side-by-side
shared assemblies.
In this scenario the application will bind with those assemblies which have
been built using the same .Net framework.
Prasen