Calling .NET Components from COM

COM and .NET Interoperability is bidirectional. What that means is that even though most scenarios require interoperability of COM objects with newer .NET applications, .NET Framework also provides interoperability on the other end, which is to utilize .NET components from COM applications. This can be particularly useful for enhancements of existing applications. For instance, take a scenario where an existing COM-based application needs a set of significant enhancements. Architects again have two options: Develop new components required for the changes in either COM or in .NET. Based on a careful evaluation of the pros and cons of each approach, it might well be true that the architect decides to develop the new set of components in .NET, leveraging the rich set of features the .NET Framework provides, but then make these .NET components available to existing COM applications so that they can be properly utilized.

SHOP TALK : INTEROPERABILITY AND/OR MIGRATION?

Whereas the subject of interoperability deals with scenarios that are aimed at coexistence, and migration is focused on actually moving into the new architecture, practically speaking, they do work together. For instance, if you are working on an initiative that aims to migrate a large application from the previous DNA architecture into .NET architecture, chances are that you will do piece-by-piece migration. In the first phase, you might migrate only the front-end components ”for example, ASP to ASP.NET ”and leave the back-end server components for a future phase. Interoperability with COM objects with ASP.NET becomes a very important tool. Similarly, if the first phase was focused on migrating the server-side logic, taking advantage of .NET Remoting and other components, runtime callable wrappers for .NET components can be used with existing ASP code instead.

Using the .NET Framework SDK ”TlbExp.exe

As part of the .NET Framework SDK, command-line based tools are provided that automate the process of generating the required type library for .NET components. The tool is the .NET Framework Assembly to Type Library Converter, also called TlbExp.exe.

Suppose that you have developed a .NET component, using Visual C#, that utilizes the new features of .NET Web services integration technologies to post a trade to a B2B trading partner. As an enhancement to your existing COM-based application, you would utilize this new .NET component from an existing Visual Basic “based COM technology environment.

 using System; using System.Reflection; using System.Runtime.InteropServices; [assembly:AssemblyKeyFileAttribute("mycompany.snk")] namespace NewTradingSystem {    [ComVisible(true)]    public class ExtTrader {       // Empty Constructor required by COM Clients       public ExtTrader() {       }       public int PostTrade(String service, String equity,                        String user, String price) {          Console.WriteLine("Posting trade to: "+service);          return 1;       }    } }

Note the System.Runtime.InteropServices.ComVisible attribute. This attribute can be set for .NET assemblies, classes and interfaces, or individual methods , and based on the level it is set, the common language runtime will expose the functionality of the .NET components for external COM objects. Another Assembly directive used in the preceding code is AssemblyKeyFileAttribute . This is required because for .NET components to be invoked from COM components, they need to be registered in the Global Assembly Cache (GAC) using the gacutil tool. As you learned earlier, only strongly named assemblies can be registered in the GAC. Hence, the public/private key “based keyfile is used, which in turn can be generated using the .NET Framework “provided strong name utility, SN.EXE.

 sn k mycompany.snk

Next , you compile the DLL into a library using the C# compiler:

 csc /target:library ExtTrader.cs

Registering the assembly in the GAC is the final step:

 gacutil /I ExtTrader.dll

Before you proceed to the next step, you may want to make sure that your .NET component is working fine from within the .NET programming environment itself. A simple C# program will do that. I strongly advise this unit test before proceeding to the next step.

 using NewTradingSystem; using System; public class PostTradeApp {    public static void Main() {       ExtTrader et = new ExtTrader();       int ret_value = et.PostTrade("http://thirdparty.com/tradingservice","MSFT",                    "hitesh.seth","50");       Console.WriteLine(ret_value);    } }

The next step is to use the .NET Framework Assembly to Type Library converter, TlbExp.exe, found in the .NET Framework SDK, to generate the type library ExtTrader.tlb, which can be referenced by COM-based applications.

 tlbexp ExtTrader.dll

Next, you need to register the .NET Assembly into the Windows Registry so that COM clients can invoke the .NET component.

 regasm ExtTrader.dll

The final step is to utilize the .NET Assembly in an existing or new COM application.

 Sub Main()     Debug.Print "Hello World"     Dim ExtTrader As New ExtTrader.ExtTrader     Debug.Print ExtTrader.PostTrade("service", "", "", "") End Sub

To compile the code successfully, you need to reference the Interop ExportTrade type library using Visual Basic's Add Reference utility (see Figure 11.7).

Figure 11.7. Adding references to the Exported Type Library of .NET component (Visual Basic).

Using Visual Studio .NET

If you are using the Visual Studio .NET application development environment, the process of registering a .NET component as a COM object is a switch that is available at the Project Options dialog box (see Figure 11.8). After that switch is enabled, type libraries for .NET components are automatically generated and registered when the project is built.

Calling .NET Components from COM