.NET COM Interop on Windows 7 64Bit gives me a headache

Question

.NET COM compatibility has always worked pretty well so far. Since I upgraded to Windows 7, I no longer try to work with my .NET COM objects.

My COM object is as simple as:

namespace Crap { [ComVisible(true)] [Guid("2134685b-6e22-49ef-a046-74e187ed0d21")] [ClassInterface(ClassInterfaceType.None)] public class MyClass : IMyClass { public MyClass() {} public void Test() { MessageBox.Show("Finally got in here."); } } } namespace Crap { [Guid("1234685b-6e22-49ef-a046-74e187ed0d21")] public interface IMyClass { } } 

also marked ComVisible.

I register the assembly using

 regasm /codebase /tlb "path" 

successfully registered (administrator mode). I tried regasm 32 and 64bit. Both times I get an error

"ActiveX component cannot create a Crap.MyClass object" using this vbscript:

 dim objReg Set objReg = CreateObject("Crap.MyClass") MsgBox typename(objReg)
dim objReg Set objReg = CreateObject("Crap.MyClass") MsgBox typename(objReg) 

fuslogvw doesn't give me any hints either. This COM object works fine on my Vista 32 bit machine.

I do not understand why I could not find a solution for this problem. Am I really the only person who ever got into this problem?

Looking at OleView, I see that my object is successfully registered. I can also create other COM objects, but it does not work only with mine.

Thanks Kevin

Answer 1

I am not a C # person, but here is a sample that I converted from VB.net. Notice, I had to make sure that I have one namespace at the project level, and then this class in VB projects. I understand that these are different in C # projects.

 [ComClass(MyClass.ClassId, MyClass.InterfaceId, MyClass.EventsId)] public class MyClass { // These GUIDs provide the COM identity for this class // and its COM interfaces. If you change them, existing // clients will no longer be able to access the class. public const string ClassId = "f58411e1-1689-4bf3-a0e1-b49f479e28ba"; public const string InterfaceId = "f4a575c6-62d2-44eb-af0f-f5b2bb65ad51"; public const string EventsId = "ad56e4f9-3512-4233-aae4-7d1c2457c08f"; // A creatable COM class must have a Public Sub New() // with no parameters, otherwise, the class will not be // registered in the COM registry and cannot be created // via CreateObject. public SalePayStatus() : base() { } } 

If COM bothers me, I always check it in the registry to make sure that the appropriate entries have been created. I found that problems with the version and installation of MSI cause problems, primarily by uninstalling (it does not clear the registry) or reinstalling, and MSI with .NET COM objects that overwrite an existing COM record causes all kinds of troubles.

Generally, you should be careful about the x64 vs x32 build.net DLL. For example, you may need to explicitly reference C: \ Windows \ SysWow64 \ or C: \ Windows \ System32 \ releases of the VBS engine.

Finally, if you are using VBS on an ASP website on an x64 server with a COM component. x32, then you will need to provide an advanced parameter for the IIS 7 application pool. The 32-bit True / False application is installed correctly.

Answer 2

Thanks! I didn’t know that there are 2 registries that I need to take care .. there was a time to switch to Win7 64 bit, I think :)

Thanks.

For everyone else who faces the same problem: wscript (a client that usually runs vbs files) runs in 64-bit mode => RegAsm 64bit should be used

Other regular clients, such as Excel, run in 32-bit mode => RegAsm 32bit is used.

Visual Studio runs in 32bit => Register for COM interop only registers a COM object in the 32-bit registry.

The only thing I need to find out is to make sure that VS Setup logs both versions