Note that the interface derives from IDispatch (required when exposing events to COM), and that I've thrown my own DISPID for the only interface method. HelloError accepts a string parameter - this might be useful if the design requires that all errors from HelloClass need to be self-describing. To use this new interface, all I need to do now is to add it as a COM source interface to HelloClass. Here's the new implementation for the hello-there class:

[ComSourceInterfaces(typeof(IHelloEvents))]
public class HelloClass : IHello {
    ...implementation goes here...
}

Note again that the class has been changed a little bit from what I wrote at the beginning of the article. See Listing 5 for all the implementation details. I've created an IHello interface, dropped the useless _name data member, and then implemented the IHello interface via HelloClass.

There's a reason why I derived my IHello interface from IDispatch in this listing; I want to show you how to use HelloClass from the old Visual Basic 6, and VB6 can't consume IUnknown objects. Of course, making IHello an AutoDual interface will do just fine, too.

The VB6 demo program will look pretty much like the one shown below. I assume you're dealing with an application containing one single form with two buttons called HelloJack and HelloNobody. Clicking on either button will call the SayHelloTo method from HelloClass. Don't forget to add a reference to the COM object you have just created.

Dim WithEvents HelloObject As HelloClass
Private Sub Form_Load()
    Set HelloObject = New HelloClass
End Sub
Private Sub Form_Unload(Cancel As Integer)
    Set HelloObject = Nothing
End Sub
Private Sub HelloJack_Click()
    MsgBox HelloObject.SayHelloTo "Jack", vbOKOnly, "Hello"
End Sub
Private Sub HelloNobody_Click()
    HelloObject.SayHelloTo ""
End Sub
Private Sub HelloObject_HelloError(ByVal hello_error As String)
    MsgBox hello_error, vbOKOnly, "Error"
End Sub

That's it! You're ready to build full-blown COM components from within Visual Studio and from your framework (and language) of choice.

The COM-Friendly User Controls: Exposing ActiveX Functionality from .NET
You might think that once you know all about the COM-related attributes from the .NET Framework, it would be very simple to implement an ActiveX control. After all, what's in an ActiveX control? You need to implement this and that interface and depending on what functionalities your control needs to support, you might want to add some events and you're ready to go.

Indeed, the UserControl class that sits at the base of every control defined by you ultimately implements a series of standard COM interfaces that are pretty much mandatory for an ActiveX control: IOleControl, IOleWindow, IViewObject, and so on - it really looks like all the hard work has already been done for you.

Not so fast. Although Microsoft has given a lot of thought to the interoperability game, ActiveX has somehow disappeared from the list. Yes, this scenario is not supported at all, and, until recently, you were on your own if you needed to build such a beauty. Up to a (fragile) point, this really could be done, but there was no guarantee that things wouldn't start behaving erratically exactly when you were ready to uncork the champagne.

I just lied to you: there was in fact just one single scenario available to you. If you really like to play with a hot potato, you could develop ActiveX controls hosted inside Internet Explorer 5.01 and later. There are many things to be considered here, all depending on your project needs - security issues, deployment, and so on. If all went fine, your UserControl objects could be brought up on an HTML page via the well-known OBJECT tag. The IE hosting scenario for .NET controls is quite a big, complex subject, and I won't go further on this road.

As an aside, what I just said was true for .NET 1.0; starting with 1.1, the framework lets you use Windows Forms from Visual C++ projects using Microsoft Foundation Classes (MFC), plus Internet Explorer 5.01 or later.

I said that you couldn't create regular ActiveX controls. Well, things have changed lately. The new kid in town is called Microsoft Interop Forms Toolkit, now in its second release, and available from http://msdn2.microsoft.com/en-us/vbasic/bb419144.aspx.

This is a free add-in for Visual Studio (actually, for Visual Basic 2005) that will help you create window forms and user controls ready to be used from Visual Basic 6. You read it perfectly: officially, the toolkit supports only VB.NET-to-VB6 scenarios. In its first release (September 2006), the Interop Toolkit allowed VB6 applications to display .NET Windows Forms easily. Exposing UserControls as ActiveX components was still in beta at that time, but the last release (May 2007) adds full support for creating such controls from VB.NET, too.

Once the toolkit is installed, you'll end up with two additional project templates for VB.NET: one for building user controls that are visible from VB6 (the InteropUserControl template) and one to allow VB6 programs to use a Windows Form (the VB6 InteropForm template). There is also a very good documentation with plenty of tutorials, as well as a series of sample projects.

Since the toolkit already comes with all that, I won't insist on this subject more than is necessary. I leave it to you to explore the powerful toys contained in this kit.

I have to say a few more things here. Although the toolkit is intended to work with VB6 projects, you can still use the resulting ActiveX controls from any COM client. An ActiveX control is an ActiveX control no matter what; be advised though that the toolkit has been created with VB6 in mind, and you should test your project carefully before going live with it.

It's been a long ride and now we're going for the home stretch. I'm sure there is enough here to make you interested in exploring other .NET-COM interoperability issues. For now, I have to summarize everything up in a nice...

Conclusion
I've only touched the tip of the iceberg in this article about the .NET and COM playground. There are still the issues of deployment to discuss, or what happens with classes that inherit from ComVisible ones, and which are exposed themselves to COM. Also, there are some issues when having overloaded methods; for example, if you have SomeMethod defined twice, what you get is a COM class whose second method is renamed to SomeMethod_2; this is a real problem for VB6, which doesn't recognize methods with underscores in their names.

Anyway, your toolbox now contains one more secret when dealing with legacy applications. This can be the beginning of a beautiful friendship between you and those old projects.