The Artima Developer Community
Sponsored Link

.NET Buzz Forum
COM Interop and .NET

0 replies on 1 page.

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 0 replies on 1 page
Greg Reinacker

Posts: 276
Nickname: gregr
Registered: Aug, 2003

Greg Reinacker is president of NewsGator Technologies
COM Interop and .NET Posted: Aug 8, 2003 1:05 PM
Reply to this message Reply

This post originated from an RSS feed registered with .NET Buzz by Greg Reinacker.
Original Post: COM Interop and .NET
Feed Title: Greg Reinacker's Weblog
Feed URL: http://sedoparking.com/search/registrar.php?domain=®istrar=sedopark
Feed Description: Greg Reinacker's Weblog
Latest .NET Buzz Posts
Latest .NET Buzz Posts by Greg Reinacker
Latest Posts From Greg Reinacker's Weblog

Advertisement

This wasn't obvious at all, so I thought I'd post this in the hopes of saving someone some pain:

If you have a non-managed application which creates a COM object implemented in managed code, by default the latest installed version of the framework will be loaded. Even if the COM object is specifically targeted to the 1.0 Framework. Took a while to finally find the docs for this:

The following factors determine the runtime version:

  • A COM application can specify the runtime version in an application configuration file. For additional information, see Configuring a COM Application for Side-By-Side Execution.
  • The runtime can already be loaded into memory by an extensible host, such as Microsoft Internet Explorer or Microsoft Office. The plug-in COM application uses the runtime that is loaded for the host to run managed components.
  • When strict control is needed, a COM application can preload a specific version of the runtime programmatically by invoking the CorBindToRuntimeHost method (exported from mscoree.dll). Alternatively, the application can target a different version of the runtime, based on an activated COM class, by invoking the GetRequestedRuntimeVersionForCLSID method (also exported from mscoree.dll) and passing the return value to CorBindToRuntimeHost.

In the absence of these factors, the startup code loads the latest compatible runtime version installed on the computer.

Interesting. Makes sense now, I suppose, but not what I initially expected.

Which leads to an interesting problem. If an application needs to use two inproc COM objects, one which only works with the 1.0 Framework, and one that only works with 1.1, you're screwed. And these objects don't even have a way to tell anyone that they only work with a certain version. Seems the only safe thing to do, if you're such a COM object, is support every version of the framework that you might be loaded into. Hmm.

Read: COM Interop and .NET

Topic: Standardizing the Patch Experience Previous Topic   Next Topic Topic: Programming Language Inventory or Serial Killer

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use