views:

43

answers:

1

I have a class library that I have written in C#.net. I want to register it with COM on my 64 bit windows machine so that I can create instances of it using CreateObject() in scripts (javascript, vbscript, whatever). So I created a setup project. I set the Target Platform of the setup project to x64. The class library project's Target platform is set for AnyCPU. I have created an Custom Action for the installer that does the registrtion of the driver manually and it looks like this...

RegistrationServices regsrv = new RegistrationServices();
if (!regsrv.RegisterAssembly(this.GetType().Assembly, AssemblyRegistrationFlags.SetCodeBase))
{           
   throw new InstallException("Failed To Register driver for COM Interop");
}

I can attach the debugger to this process when it runs and know for certain that this registration occurs successfully.

For some reason, when I try to create an object of the class using CreateObject() it gives me an error saying "Could not create object named ...". However, if I run the script using the cscript.exe in the SysWOW64 folder (the 32bit folder) the object is created successfully and the rest of my script runs fine. So it appears as though the class is being successfully registered for 32bit but not for 64, OR that my project has a 32 bit dependancy and the 64bit Cscript host process can not create it because of that dependency. My class library does reference one other project that I wrote but it is also set to build for ANY CPU. So it should be good for 32 and 64 bit processes.

Does anyone have any suggestions on how I should track down this 32bit dependency?

+1  A: 

Using RegisterAssembly() is very unusual. One thing that could go wrong here is that the installer is running in 32-bit mode. Which would make RegisterAssembly() register the COM server in the wrong registry section.

No need to do this, just set the Register property for the file to COM in the setup project.

Hans Passant
I did that as well before I tried RegesterAssembly(). No luck.
Jordan S
Use SysInternals' ProcMon tool to see what the installer actually does.
Hans Passant
I have tried this but it's hard to find what I'm looking for. Any tips on what I should filter for?
Jordan S
See what registry keys are being written. You've got a problem if it writes to HKLM\Software\Wow6432Node, that's for 32-bit apps.
Hans Passant
I discovered that using VS2010 instead of VS2008 fixes this problem. The manual registration is not necessary as you said.
Jordan S