Accessing a .NET Assembly from classic ASP

Question

I have been trying to access a .NET Assembly that I have created in classic ASP using

dim foo
set foo = Server.CreateObject("TestAssembly.MyClass")

The problem is I'm getting an error:

Server object error 'ASP 0177 : 800401f3'

Server.CreateObject Failed

/test.asp, line 4

Invalid class string

I have registered the assembly (TestAssembly.dll) using gacutil and regasm as instructed in the article: Replacing Old Classic ASP COM Components with .NET Assemblies which I referenced from another question. It supplies two methods in which to install the assembly and I have tried both, but to no avail.

Getting this working would be great because it would allow me to gradually migrate a classic ASP site to .NET

Answer 1

This error means "Invalid class string" -- in other words the call to CreateObject failed because the name object cannot be found by the OLE sub-system. Causes include:

1. You really didn't run regsvr32 on the server after all.
2. You ran regsvr32 but it reported an error.
3. Someone modified security on part of the registry that's preventing the OLE subsystem from reading all or part of the HKEY_CLASSES_ROOT tree.
4. The name of the object you are trying to create was mispelled or is incorrect.
5. Determine if it's a permissions problem

Add the anonymous user (used by IIS) to the Administrators group. The test page then worked, proving it was a permissions problem. Do not forget to remove the anonymous IIS user from the Admin group!

1. Determine if it is a file permissions problem:

After removing the Anonymous user from the Admin group, add failure auditing to the file (smtpsvg.dll), which will determine if the file was ever accessed (by the lack of the failure event). If it isn't, this makes it clear that the failure is prior to file access but go ahead and check file/directory permissions to make sure the anonymous IIS user can access the file.

1. Check registry permissions

Using Regedt32, do find on smtpsvg.dll. Check the permissions for the key (and sub keys), and make sure that the anonymous user has read rights. Do a find on the class-id, which contains the location value, and version, and check those permissions as well.

source: http://forums.digitalpoint.com/showthread.php?t=21069

Answer 2

I have had problems in the past with calling .NET assemblies from ASP Classic. I think this was one of the several problems I ran into along the way.

One of the things I had to do to make things work was to make sure the Application Pool for the ASP site was using the same identity as the anonymous user (by default it uses "System User" or something like that). So I ended up creating a new local user (making sure it is a member of the IIS_WPG group) and using that for both the IIS anonymous user and the App Pool identity.

This is a troublesome area though, the app I was using it for was a shrink wrapped product and we found that some machine were screwed up in such a way that we simply couldn't get ASP Classic to .net calls to work even after lots of tweaking of permissions and the like.

Edit:

I guess I should say that I'm not claiming this change will fix this particular problem, just that this was one of the changes we had to make to make out ASP Classic -> .NET code work on a wide range of random customers servers.

Answer 3

Another thing to check: make sure your .Net assembly is set to be COM Visible.