How to register a DLL using PowerShell without RegAsm

Question

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?

Solution 1

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.

Solution 2

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.

Comments

[Ian McShane]

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.