Calling COM exposed .net assembly from unmanaged code

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I have a .net assembly (dll) that is com exposed and is build with 1.1
framework. My main application is in unmanaged c++ EXE. I make a cocreate and
create my .net assembly in it. After installing the .net 2.0 on the machine,
it seems that whenever my .net assembly dll is loaded, it loads the .net 2.0
dlls and not 1.1 dlls. My registry for the .net assembly has the Runtime
version as 'v1.1.4322'. But when my application creates an instance of my
..net assembly, it loads the .net 2.0 dlls. This is causing some problem in my
assembly. If i try to use the same from a managed C# application, it loads
the .net 1.1 dlls correctly. Why doesn't it do the same from an unmanaged c++
application? It seems to ignore the Runtime version flag and always load the
latest version available. Is this a bug? Any feedback would be appreciated.
 
My guess is that the fault lies in the COM Interop DLL. It must indicate
somewhere that the version is 2.0.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
Who is Mighty Abbott?
A twin turret scalawag.
 
If unmanaged code needs to load a runtime it will load the latest version on
the system. The RuntimeVersion string in the registry does not affect this -
the COM client ends up having mscoree.dll instantiate your .NET COM class in
the latest framework. The documentation isn't very clear in this area, but
I've seen RuntimeVersion described as the runtime version that was used to
build the assembly, not the one required to be loaded to run it. In general
we have to expect that there are scenarios where 1.1 assemblies will run in
the 2.0 framework because apart from the COM situation, 2.0 can load 1.1
assemblies, and I've been bitten by this COM behavior too.
 
i found a solution to my problem. In order to force my COM application to use
a particular run time, i had to create a .config file for my executable. e.g.
myapp.exe.config. In that config file, supply the following entries,
<configuration>
<startup>
<supportedRuntime version="v1.1.4322" />
</startup>
</configuration>

This will make sure that my COM app will always load the specified runtime
in the config file and not the latest one available.

Phil Wilson said:
If unmanaged code needs to load a runtime it will load the latest version on
the system. The RuntimeVersion string in the registry does not affect this -
the COM client ends up having mscoree.dll instantiate your .NET COM class in
the latest framework. The documentation isn't very clear in this area, but
I've seen RuntimeVersion described as the runtime version that was used to
build the assembly, not the one required to be loaded to run it. In general
we have to expect that there are scenarios where 1.1 assemblies will run in
the 2.0 framework because apart from the COM situation, 2.0 can load 1.1
assemblies, and I've been bitten by this COM behavior too.
--
Phil Wilson
[Microsoft MVP-Windows Installer]

Gopal said:
I have a .net assembly (dll) that is com exposed and is build with 1.1
framework. My main application is in unmanaged c++ EXE. I make a cocreate
and
create my .net assembly in it. After installing the .net 2.0 on the
machine,
it seems that whenever my .net assembly dll is loaded, it loads the .net
2.0
dlls and not 1.1 dlls. My registry for the .net assembly has the Runtime
version as 'v1.1.4322'. But when my application creates an instance of my
.net assembly, it loads the .net 2.0 dlls. This is causing some problem in
my
assembly. If i try to use the same from a managed C# application, it loads
the .net 1.1 dlls correctly. Why doesn't it do the same from an unmanaged
c++
application? It seems to ignore the Runtime version flag and always load
the
latest version available. Is this a bug? Any feedback would be
appreciated.
Click to expand...
Click to expand...
 
Back
Top