Creating a COM object for Classic ASP

Are you stuck in Classic ASP, but need or want to use some .net code?  Creating a COM object for Classic ASP might just be your solution.  Creating a .net assembly and making it COM Visible is simple to implement and deploy.

Making a .net assembly COM Visible

Create a .net class library

Create a .net class library.  File  > New Project > Class Library

Create a public interface, generate a new GUID & apply attributes

To make a .net assembly COM visible, you must use an Interface implementation.  You must attribute the interface to make it COM visible.  You must generate a new & different GUID for each interface

using System.Runtime.InteropServices;
namespace YourCompany.COM.Interfaces
{
    [ComVisible(true)]
    [Guid("34ec10d2-504f-4376-b046-1200c7d06249")]
    [InterfaceType(ComInterfaceType.InterfaceIsIDispatch)]
    public interface ICOMWrapper
    {
        string Execute(string json);
    }
}

Implement the interface, generate a new GUID & apply attributes

To implement the Interface, you must attribute the class to make it com visible.  You must generate a new & different GUID for each class that implements the interface.

If you class needs to read any config values from an app.config file, you must refresh the configuration manager.  See “Using config values” section for details…

You must attribute each public method that you would like to make com visible.

    [ComVisible(true)]
    [Guid("bd52c368-7cd0-46ad-a6ea-d13edd50fb20")]
    [ClassInterface(ClassInterfaceType.None)]
    [ProgId("YourCompany.COM.AddressValidator")]
    public class AddressValidator : ICOMWrapper
    {
        public AddressValidator()
        {
            ConfigurationUtility.RefreshConfigurationManager();
        }

        [ComVisible(true)]
        public string Execute(string json)
        {
           // Implement your method here...
        }
    }
}

Build and deploy

Build your assembly in Release mode and copy out the files from the Bin/Release folder

Using config values

The COM object does not read configuration values without a little help.  You must set CurrentDomain of the app.config file and refresh each section (appSettings, system.serviceModel, etc…)

        public static void RefreshConfigurationManager()
        {
            var targetAsm = Assembly.GetExecutingAssembly();
            var configFile = targetAsm.Location + ".config";

            //Set the current domain config file so sections can be refreshed
            AppDomain.CurrentDomain.SetData("APP_CONFIG_FILE", configFile);

            //Needed for WCF Proxy to read bindings
            ConfigurationManager.RefreshSection("system.serviceModel");

            //Needed for appSettings
            ConfigurationManager.RefreshSection("appSettings");
        }

Registering the COM object on the server

Initial Registration

  1. Open Command Prompt
    1. Start > cmd
  2. Navigate to regasm.exe dir
    1. cd C:\Windows\Microsoft.NET\Framework\v4.0.30319
  3. Register Assembly
    1. regasm<path to your .dll> /tlb /codebase

Updating the .DLLs

  1. *Stop Application Pool
  2. Copy Files
  3. Start Application Pool

*You must stop the app pool for the COM objects
**Unregister & Register only needed if new methods have been added as COM visible

If the Interface Changes

  1. Open Command Prompt
    1. Start > cmd
  2. Navigate to regasm.exe dir
    1. cd C:\Windows\Microsoft.NET\Framework\v4.0.30319
  3. Unregister assembly
    1. regasm <path to your .dll> /u
  4. Register Assembly
    1. regasm <path to your .dll> /tlb /codebase

Using the COM object in Classic ASP

To use the COM object in Classic ASP you simply create and object, call the method and dispose the object.  The name of the COM object correlates to the ProgId attribute on the class.

	Const COM_OBJECT_NAME = "YourCompany.COM.AddressValidator"
	Dim oCOM
	Set oCOM = createobject(COM_OBJECT_NAME)

	Dim jsonResponse 
	jsonResponse = oCOM.Execute(json)

	Response.ContentType = "application/json"
	Response.Write(jsonResponse)

	Set oCOM = Nothing

Gotchas

  • The app pool worker process locks the .DLLs, so you must stop the app pool before updating the dlls.
Nate Bunton

Nate Bunton is a Lead Software Engineer at Meta Payment Systems. He has over 10 years developing software and leading teams. He works with the Microsoft technology stack focusing in ASP.NET, MVC, HTML, JavaScript, CSS and Web Security. Nate also focuses on Application Lifecycle Management (ALM) engaging his teams with key stakeholders using a variety of agile principals. At Meta Payment Systems, Nate has been a leader in driving technology in the enterprise from new Web Technology to Service Oriented Architecture using WCF and NServiceBus. Nate’s greatest passion is for User Experience, Web Technology and Engaging Teams. He is driven by his desire for continuous learning & improvement.

Posted in Web Development Tagged with: , , , ,