|
dev
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Calling COM exposed .net assembly from unmanaged codeI 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. -- Show quoteHTH, Kevin Spencer Microsoft MVP ..Net Developer Who is Mighty Abbott? A twin turret scalawag. "Gopal" <Go***@discussions.microsoft.com> wrote in message news:C31E3B4C-ED58-4E76-94DF-95544E5DB9F3@microsoft.com... >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. 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. -- Show quotePhil Wilson [Microsoft MVP-Windows Installer] "Gopal" <Go***@discussions.microsoft.com> wrote in message news:C31E3B4C-ED58-4E76-94DF-95544E5DB9F3@microsoft.com... >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. 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. Show quote "Phil Wilson" wrote: > 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" <Go***@discussions.microsoft.com> wrote in message > news:C31E3B4C-ED58-4E76-94DF-95544E5DB9F3@microsoft.com... > >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. > > >  |
|||||||||||||||||||||||
Other interesting topics