Some companies (I won’t name names) are unfortunate enough to be stuck with continuing use of ActiveX COM DLLs. Sure, it’s easy to upgrade to .NET for brand spankin’ new development projects, but problems become apparent when it’s time to redevelop a legacy product where you are stuck using some old ActiveX references. Of course, the real answer here is to redevelop the ActiveX DLLs, but sometimes that is not in the immediate timeline. One way around this issue is to create a .NET wrapper for the DLL and reference that in the redeveloped product.

These instructions should be work with Visual Studio 2010 all the way down to Visual Studio.NET 2003.

  1. Create a new project for the wrapper. Select a type of Class Library. I like to name it after the DLL and append “Wrapper” to the end of my project name so it is clear what ActiveX DLL is being wrapped.
  2. Delete the Class1.cs (C#) or Class1.vb (VB.NET) file that is automatically generated. There is a better template included in Visual Studio that should be used instead.
  3. Add a new class file to the project. Select a template type of Component Class (or COM Class in older VS versions). This will add the necessary COM GUID and a default constructor, which are both required for COM interoperability.
  4. Add the ActiveX DLL reference to the project from the COM tab or by browsing to the the DLL directly.
  5. Reference the imported ActiveX control by adding the necessary “using” (C#) or “Imports” (VB.NET) statements in the class.
  6. In the public class declaration, implement your control with “:” (C#) or “Implements” (VB.NET).
  7. Declare a class-scope instance of the wrapped object. For example:

    private OriginalComponent _wrappedComponent;
    Dim _wrappedComponent as OriginalComponent

  8. Use the Object Browser on the ActiveX reference to find out what functions you need to wrap, and the necessary arguments for the functions. The constructor doesn’t actually run during COM interop, so you have to check or create the objects in each overridden/implemented function call. C# overrides the function names, while VB.NET has to Implement each function specifically. For example:

    public <Return Type> WrappedFunctionName(<Arguments>)
    if (_wrappedComponent is null)
    Object tempObject = CreateObject("<ProgID of Wrapped DLL>");
    _wrappedComponent = tempObject;
    tempObject = null;
    return _wrappedComponent(<Arguments>);
    Public Function WrappedFunctionName(<Arguments>) As <Return Type> Implements _wrappedComponent.<function>
    If _wrappedComponent Is Nothing Then
    Dim tempObject as Object = CreateObject("<ProgID of Wrapped DLL>")
    _wrappedComponent = tempObject
    tempObject = Nothing
    End If
    WrappedFunction = _wrappedComponent(<Arguments>)
    End Function

  9. To use, build the project and reference the resultant project DLL. Make sure you including all the bin directory contents including the Interop assemblies if you copy the compiled project elsewhere, or it will not work.
  10. Depending on your implementation (for example, if you are implementing on a Web server), you may have to register the project DLL using RegAsm.
Like this post? Share it!