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\")
I used icepicker's solution and it worked for me. I spent over a day looking into this error i was getting
Microsoft VBScript runtime error '800a01ad'
ActiveX component can't create object: 'namespace.class'
/page.asp, line 15
The solution was to use the c:\Windows\microsoft.net\framework64(folder of framework used)\regasm). I was running this from c:\Windows\microsoft.net\framework64 & c:\Windows\microsoft.net\framework and it did not work. My assumption is that if you run REGASM it will default to the 32 bit version. Unless you specify the framework64/v4.0.x.x.x (or whatever version) folder, only then it will run the 64-bit.
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.
Another thing to check: make sure your .Net assembly is set to be COM Visible.
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:
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!
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.
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
Check in the registry here: *HKLM\SOFTWARE\Classes* and see if the namespace.class is there (e.g. "TestAssembly.MyClass") and that it has a key called "CLSID" with a valid ID.
If the registry entry isn't there then make sure that Project > Properties > Assembly Information has "Make assembly COM-Visible", then recompile. Once compiled, run regasm (if you're on a 64bit machine they you will have to explicitly reference the 64bit version of regasm - c:\Windows\microsoft.net\framework64\v4.0.30319\regasm) with:
regasm /codebase /tlb TestAssembly.dll