One of the many questions surrounding Microsoft.NET is how quickly it will be adopted by developers. Even if your organization begins using .NET immediately, the syntax changes in Visual Basic.NET mean that all your existing applications probably won’t be immediately converted to the new language. A situation may arise, then, in which you have an existing VB client application that makes use of a variety of COM services and that needs access to a new .NET component. In this article, I’ll show you how cope with such a situation and illustrate some of the pitfalls in doing so.
Most experts agree that the future of .NET is largely dependent on how well it interoperates with existing COM applications. Microsoft is aware of this and has gone to some lengths to make .NET easily backward compatible with COM.
Register here, please
First, let’s review how the system manages a COM library. When a COM component is installed, several registry entries must be created to tell the operating system where the component is located and to provide the names of the classes in the component. Components also provide a type library that contains information about the classes in the component, like method signatures. (For a VB-centric explanation of how Windows manages COM components, see “Demystifying version compatibility settings in Visual Basic”.)
In contrast, .NET components do not need to be registered in the traditional way when installed, and they don’t provide type libraries: That information is contained inside the component’s assembly, in what’s called a manifest. The command-line utility RegAsm.exe is used to make the registry edits and create the type library necessary for a COM client to use the assembly. After a component has been registered and its type library has been created, it can be used exactly as if it were a COM component; both early and late binding are supported.
Let’s look at an example of this process. In Listing A, I’ve created a sample VB.NET class library that returns the value of Timer() as a few data types and provides a simple form that can be displayed via the ShowForm() method. In Listing B, I’ve created a simple VB6 client application that uses the component.
Assuming that you have the .NET Framework installed:
- · Download the compiled projects and extract Net2ComSample.dll to a temporary folder.
- · Open a command window and change to the sample folder that contains Net2ComSample.dll.
- · Register Net2ComSample.dll and create its type library with this command: RegAsm Net2ComSample.dll /tlb Net2ComSample.tlb
- · Open the DotNetClient project in Visual Basic 6.
- · Compile the project into the Net2ComSample.dll’s folder (see below to find out why) and run the exe.
At this point, you should be able to click any of the buttons on the client application’s form to call their corresponding .NET methods. As the example illustrates, it’s even possible to display a .NET form through this mechanism.
If you examine Net2ComSample with the VB6 object browser, as shown in Figure A, you’ll notice that the library contains more than just the four methods in its source code.
|Figure A: The Object Browser examining Net2ComSample|
|Where’d all those come from?|
All these extra methods are inherited from SampleClass’s base class, Object, and are themselves callable from Visual Basic.
A few precautions
At first glance, making VB6 use .NET components seems simple, but there are several things to keep in mind:
- · VB6 doesn’t know how to pass arguments to a class’s constructor, so make sure that the .NET class has an appropriate constructor.
- · Although most .NET primitive variable types will map to their VB6 counterparts with no trouble, remember that some variable type names have changed, and some old names now have new meaning (VB6’s Integer type, for example).
- · Because of the method used by .NET to locate assemblies, the server assembly must either be located in the same folder as the client executable or in the Global Assembly Cache.
- · Remember that, as of this writing, VB.Net is beta software.
The realities of software maintenance mean that very few existing VB applications will be immediately converted to VB.NET. Furthermore, those realities make it likely that existing applications will need to be enhanced before time can be found to convert them. Taking advantage of the backward compatibility Microsoft has built into .NET can help make the transition to this new environment easier.