ZDNet UK


Skip to Main Content

ZDNet.co.uk - Winner of Best Business Website 2007
  1. Home
  2. News
  3. Blogs
  4. Reviews
  5. Prices
  6. Resources
  7. Community
  8. My ZDNet

 

ZDNet UK RSS Feeds


IT Jobs

Application development Toolkit

COM and .Net interoperability

S. Vikram Builder.com

Published: 21 May 2002 15:18 BST

  • Email
  • Trackback
  • Clip Link
  • Print friendly
  • Post Comment

Although new development may be carried out using .Net, there will be a need to reuse some of the functionality existing in the form of COM components. In this article, I examine some COM and .Net interoperability techniques.

COM to .Net: A shift in technology
Though a COM component and a .Net assembly share the same .dll extension, things are not the same internally. A .Net assembly does not need information about it to be stored in the registry, but instead holds the type information in the form of metadata. This metadata is present within the assembly itself. Further, a .Net assembly is not based on the IUnknown interface, which is an interface exposed by all COM objects.

The code that exists in the form of COM is known as unmanaged code, because the execution of this code is not managed by the common language runtime (CLR). Code written with the .Net Framework is managed by the CLR and is hence known as managed code.

It is impractical to rewrite every piece of code in .Net, because a lot of functionality exists in COM form. Moreover, more code exists in COM today than .Net, because .Net is a relatively new platform. From this fact arises the need for interoperating between COM and .Net. The .Net Framework has dedicated a namespace for this purpose. The System.Runtime.InteropServices namespace provides classes that can be used for accessing COM objects from .Net. We will begin by calling COM objects from .Net -- a common necessity.

Calling COM objects from .Net
The code within a COM object is not executed by the CLR. The mechanism followed to expose a COM object to .Net is as follows: The COM object is encapsulated within a wrapper class, and this exposes the COM object as a .Net assembly to the CLR. This wrapper is known as the runtime callable wrapper (RCW). This process is illustrated in Figure A.


Figure A
Runtime callable wrapper (RCW)

This wrapper class (RCW) acts as a bridge between the unmanaged and managed code, and all operations are routed through this class. That's enough theory; let's take a quick look at how this can be done. The entire process of generating an RCW is automatically handled by Visual Studio.Net.

Next

Previous

1 2 3


  • Email
  • Trackback
  • Clip Link
  • Print friendly Print with Kyocera

Did you find this article useful?
115 out of 224 people found this useful


Full Talkback thread

1 comment

  1. It would be nice to access your site without that... Keith Hamilton

Company/Topic Alerts

Create a new alert from the list below:













Related Jobs

Senior VC++ Software Engineer - MFC / Visual Studio/ SQL - Basingstoke

Senior Software Engineers - C++ using Microsoft Visual Studio and MFC. Key technical skills will include strong skills in C++ using Microsoft Visual ...

Quality Lead - Unilever - Level C-00055185

Support implementation coordination for agreed QPI, SOX and Security controls Manage one quality team member who will support these activities Main ...

SAS Basel Modelling Team Leader 40-50k Halifax

A good business and technical understanding of the scope and key parts of the Basel Framework At least 12 months 'hands on' experience of Probability ...

Featured Talkback

The fact is: Software developers today are really designers and not coders. The reason that business anlaysts exist today to model solutions is because they understand the value of designing software before writing it. All too often developers create code that has little value because they do not understand that business classes interact with other classes within the confines of a working model or pattern.

By: 1000165269

Read full story:
Making sense of agile modelling