I’ve lost count of how many times I’ve come across full-fledged systems that were created 10 years ago when classic ASP was acceptable commonplace. Back then of course, classic ASP was cool. The shift from static HTML to dynamically generated content was a compelling one, and to be fair it has served its purpose well.

The problem is that these legacy systems don’t just stop being developed. Bugs are found daily and they must be fixed. Over time, new features must be developed in order to satisfy market competition. The fast moving nature of software development means that we love to work with the cool new technologies, not the age-old ones. As such, this legacy classic ASP situation presents a problem for a lot of organisations.

Classic ASP is not taught anymore. Universities don’t care about it and developers learning in their own time are far more likely to venture into cooler new technologies. Ultimately this results in developers who have no working knowledge of classic ASP or developers who possess a working knowledge of it, but are unwilling to take positions where they’ll be stuck working with ancient technology.

Most commonly the solution to this problem is a roadmap that envisages an entire rewrite of the system in some newer and more robust technology. In the Microsoft space, this rewrite is almost always a .NET one. The full rewrite concept doesn’t immediately address the issues with the existing legacy code. Developers are still going to be writing those new features in classic ASP and still spending a significant portion of their time under the constraints of the older technology.

If you’ve spent any time working with classic ASP, you’ll know that the only extensibility point is COM; another ancient technology. Sure, you could write a COM component to do some job but then you’re still working with an old technology. You would be swapping one hell for another, right? Fortunately, Visual Studio and the .NET framework make this whole story a bit cleaner.

What I’ll describe below is a method of creating your component as a regular C# class library and exposing it as a COM object. If you’re migrating a code base from classic ASP to .NET, this method could help that process be a little more progressive. Similarly, if you need some functionality that would be easier to implement using .NET (image compression or encryption) you can use this approach instead of purchasing an expensive third party component.

So, to begin with create a new class library project. I’ll use C# here but you may use any CLR compliant language you wish. For the sake of verboseness, let’s create a simple class that does some string echoing.

   1:  namespace Library

   2:  {

   3:      public class Example

   4:      {

   5:          public string Echo(string input)

   6:          {

   7:              return DateTime.Now.ToString() + ": " + input;

   8:          }

   9:      }

  10:  }

The next step is to make this class visible through COM, which is going to let us instantiate it from any COM-capable language. To do this, right click your project and select properties to bring up the property page. On the Application tab, click the Assembly Information button. On the new window, check the box at the bottom labelled Make assembly COM-Visible and save changes.

In order to register the assembly as a COM component the assembly must be signed. Same deal as before, but don’t choose the Application tab, instead select the bottom tab named Signing. Check the box labelled Sign the assembly and choose the ‘<New…>’ option from the drop down list. You’ll now see the following:

Enter a name for the key file and enter a password to secure it. When you’re done, press OK and save changes just like before. You’ll be pleased to know that our assembly is now ready to be registered as a COM object.

The next thing you want to do is build your project so that you have access to the binary .dll file produced by the build process. We’re going to move this binary into a more permanent location. The most common place to put it is in the Windows\system32 directory. So in my case, I’ve copied the ClassicCOM.dll file into the C:\Windows\system32 directory.

The final step is to invoke the regasm tool that is deployed with the .NET framework. The regasm tool will create the necessary entries in the registry for our new COM object. Let’s start up a command prompt and navigate to the directory containing the regasm tool.

We’ve changed the current directory to C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727 and now we should be able to register our COM object by invoking regasm with the necessary parameters.

By executing regasm with the name of the .dll file that we copied into system32 earlier and the /codebase parameter we have successfully registered our COM component. To test this, let’s create a simple VBScript file that will attempt to create an instance of our Example class and call the Echo method.

   1:  dim echoObject, result

   2:  set echoObject = CreateObject("Library.Example")

   3:   

   4:  result = echoObject.Echo("Hello from VBScript")

   5:  msgbox(result)

Notice that on line 2 we create an instance of our Example class by referencing the namespace Library followed by the class name. Our echoObject variable is now an instantiation of our C# Example class and as such we’re able to call the Echo method on line 4. The result is shown below:

And there you have it, classic ASP and .NET working together. With this technique you have an extended toolset. It’s not the case anymore than you have to buy the image resizing component for $20 because you have no other choice.

This technique also forces a certain amount of modularisation on your code – which can only be a good thing with classic ASP’s track record for clean code. You could create an elegant hierarchy of COM libraries that do the dirty work of your application and simply call this from your classic ASP code. That’s not to say ONLY from classic ASP either, the components you create as COM objects will instantly be available to any language that supports COM – which is almost all of them.

Let me finish by saying this: classic ASP and COM are both old technologies and should be avoided completely if possible. However, in situations where you’re developing that new feature for the old legacy classic ASP system, doing the work in .NET and exposing it to the legacy system through COM can have its advantages. Notably speed, cleaner and more testable code and an easier transition into your new codebase are some of the benefits to be had. On the other hand, one could easily over-do it and attempt to abstract away the entire existence of classic ASP. Be careful to strike a nice balance that allows you to reach your goals in the best possible way.