Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I have an ASP Classic application which references some Visual Basic 6.0 COM objects. One of these Visual Basic 6.0 COM objects reference another third-party DLL.

The third-party DLL needs to be registered on a Windows Server 2008 R2 x64 machine.

I have found scripts to register the DLL in the GAC without GACUTIL using PowerShell (ref: http://weblogs.asp.net/adweigert/archive/2008/10/31/powershell-install-gac-gacutil-for-powershell.aspx).

Now I need to register the assembly. I have used both the GACUTIL and the RegAsm on my local development machine (x86) without hitch. But when I try to get the DLL on the testing server I have problems.

First issue: No GACUTIL.

That is, there is no GACUTIL on the server, which I got around using the script noted above.

Second issue: RegAsm cannot find assembly.

The RegAsm under the 32-bit .NET Framework does not find the DLL. Error reported:

RegAsm : error RA0000 : Unable to locate input assembly 'C:\Windows\System32\xxxxx.dll' or one of its dependencies.

So I used the 64-bit variant and that worked.

But when I run my application I get errors in my event log:

ActiveX component can't create object.

Generally speaking that happens because it cannot find the object to create, which means that the DLL hosting the object is not registered correctly.

So what I am trying to do now is find out if there is an alternate method to RegAsm using PowerShell.

Is that possible and what would the script be to get it right?

share|improve this question
    
Thanks for the edit TiZon, used to CAPS for subject lines. –  Ian Mc Shane Mar 30 '11 at 8:07

4 Answers 4

Not sure, but your trouble seems to come from a side effect of UAC Virtualisation (this article can also help) which exists from Vista and is still valid here. An abstrat is that system parts of the file system and registry are now protected from user access, but to assume that old (32 bits) programs continue working the system make them believe they write on these parts, but in fact he redirect them to user's places. Have a look in "HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node" in your registry.

A trouble I encounter recently is that my MSI was built with a 32 bits librarie, so invoking these libraries during installation on a 64 bits machine make UAC virtualisation install my registry keys in Wow6432Node. This Internet article helps me to solve the problem. I use Orca to replace Installutillib.dll from 32 to 64 bits.

share|improve this answer

RegAsm and GacUtil are for .NET assemblies. For a COM component (in a dll) you need to use regsvr32.exe.

COM registration is a completely different process to .NET, and regasm spans the gap by wrapping a .NET assembly in a COM Proxy to make it usable within COM—it is one of the interop possibilities.

NO GACUTIL

GacUtil comes with the .NET SDK, for non-developer systems its work should be done by the installer.

share|improve this answer
    
The 3rd Party DLL is an .Net assembly... under the GAC (WINDOWS\ASSEMBLY) it comes up as MSIL under the Processor Architecture. So that is why I am using the RegAsm and GacUtil. Thanks for the info on the GACUTIL SDK relationship. –  Ian Mc Shane Mar 29 '11 at 10:52
up vote 0 down vote accepted

I found out that I was placing the .NET DLL in the incorrect folder on the test machine for registration.

On a Windows 64-bit OS you have the System32 and the SysWOW64 folders. I placed my DLL in the System32 folder, where it should have been in the SysWOW64 folder.

The error I got from RegAsm:

RegAsm : error RA0000 : Unable to locate input assembly 'C:\Windows\System32\xxxxx.dll' or one of its dependencies

should have made me click, but I missed it.

Basically the 32-bit RegAsm could not find my DLL but the 64-bit RegAsm could find my file and by registering the assembly with the 64-bit RegAsm I was putting the DLL into the 64-bit scope. I needed it to be in a 32-bit scope.

I moved the DLL form System32 to SysWOW64 and the 32-bit RegAsm found the DLL and registered it within the 32-bit scope.

Now my Visual Basic 6.0 COM object can find the .NET DLL, and it works without the error "ActiveX component can't create object".

With all that said, I have not found a library or function that will do the same job as RegAsm without actually using RegAsm.

If anyone finds this mythical beast please reply to this question.

share|improve this answer

If you want to use regsvr32.exe in PowerShell use CMD first. This will open a cmd window in PowerShell. It is just a nifty trick I learned, but I'm sure you know this already working with DLLs and COM objectCs for Windows.

share|improve this answer
    
Nice, thanks for the info. –  Ian Mc Shane Mar 30 '11 at 8:44

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.