Registering a .NET DLL for COM visibility in ASP Classic

Question

We're trying to write a couple of applications. One ASP.NET site uses the .NET Assembly xxx.Elements.dll, which provides utility functions.

The other, a Classic ASP site, should also use the same DLL in order to use the same utility functions. (It will be used for encrypting data between the two sites).

Despite many attemps and Googling, we cannot get this working.

We have:

Applied ComVisibility to the Assembly.info and ensured there is a Guid:

[assembly: ComVisible(true)]
[assembly: Guid("ab96fbc3-aa39-4fb6-8628-13778445e503")]

We made sure our type ticks the boxes on type visibility by ensuring it has a default constructor, is ComVisible and has a Guid. We've also created a simplistic method for testing:

namespace xxx.Elements
{
    [GuidAttribute("D3BE2C7D-7550-4da1-8F61-6871E193242F")]
    [ComVisible(true)]
    public  class UrlUtility : IUrlUtility
    {

        public UrlUtility()
        {
        }

        public string Test()
        {
            return "HellO";
        }

    }
}

Using the interface:

[GuidAttribute("D3BE2C7D-7550-4da1-8F61-6871E193242A")]
[ComVisible(true)]
public interface IUrlUtility
{
    string Test();
}

We found this really useful (though non-resolving) post here to do this: warning MSB3391: does not contain any types that can be unregistered for COM Interop.

We have also checked the Regsiter for COM-Interop in the Project property pages.

This continues to output the warning:

c:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets(3341,9): warning MSB3214: "D:\dev\yyy\xxx.Elements\bin\Release\xxx.Elements.dll" does not contain any types that can be registered for COM Interop.

when compiling. If we run REGASM xxx.Elements.dll /tlb directly, we get:

Microsoft (R) .NET Framework Assembly Registration Utility 4.0.30319.1 Copyright (C) Microsoft Corporation 1998-2004. All rights reserved. Types registered successfully Assembly exported to 'D:\dev\yyy\IWW.Elements\bin\release\xxx.eleme nts.tlb', and the type library was registered successfully

So a little confused about the ambiguity.

When we look in the registry, it does appear to register the .tlb correctly:

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\TypeLib\{AB96FBC3-AA39-4FB6-8628-13778445E503}]

[HKEY_CLASSES_ROOT\TypeLib\{AB96FBC3-AA39-4FB6-8628-13778445E503}\1.1]
@="Elementary support library for xxx' products"

[HKEY_CLASSES_ROOT\TypeLib\{AB96FBC3-AA39-4FB6-8628-13778445E503}\1.1\0]

[HKEY_CLASSES_ROOT\TypeLib\{AB96FBC3-AA39-4FB6-8628-13778445E503}\1.1\0\win32]
@="D:\\dev\\yyy\\xxx.Elements\\bin\\Release\\xxx.Elements.tlb"

[HKEY_CLASSES_ROOT\TypeLib\{AB96FBC3-AA39-4FB6-8628-13778445E503}\1.1\FLAGS]
@="0"

[HKEY_CLASSES_ROOT\TypeLib\{AB96FBC3-AA39-4FB6-8628-13778445E503}\1.1\HELPDIR]
@="D:\\dev\\yyy\\xxx.Elements\\bin\\Release"

We have also registered the type in the GAC:

gacutil /i xxx.Elements.dll

and given it a strong name using:

sn -k xxx.Elements.snk

and included the name in the AssemblyInfo.cs file:

[assembly: AssemblyKeyFile(@"D:\dev\yyy\xxx.Elements\xxx.Elements.key")]

We have also applied the IUSR user Read permission to the registry keys:

HKEY_CLASSES_ROOT\TypeLib\{AB96FBC3-AA39-4FB6-8628-13778445E503}
HKEY_USERS\S-1-5-20\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Zones

(the last one was suggested here: Cannot instanciate .Net COM object in classic ASP/VBScript page (Error ASP 0177))

Despite all this, when we activate the object in the ASP page using the code:

dim urlUtility
set urlUtility = Server.CreateObject("xxx.Elements.UrlUtility")
' should return "Hello"
test=urlUtility.Test()

The process stops and when we debug into the W3WP process, we get the error:

Server object: 006~ASP 0177~Server.CreateObject Failed~800401f3

We have tried to check all the boxes, but we must be missing something. Any ideas, please?

800401f3 is "Invalid class string", not sure if that helps... — Nick
That could be correct, but we checked the registry and it seems to mirror other successfully registered dll's, particulary as it fails at the CreateObject call. — Mantidae

Dirk Brockhaus Dirk Brockhaus · Accepted Answer · 2010-11-16T14:30:05

I had a similar problem some time ago. I solved it by hosting the .NET component in the COM+ application server. This article suggests and describes the same. In addition to the article it maybe necessary to configure your assembly (It is running stand-alone, if you do as suggested). In this case you need a manifest and a config file in the applications root. Look at this SO answer for details.

Registering a .NET DLL for COM visibility in ASP Classic

1 Answers