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

.NET COM interop so far always has been working quite nicely. Since I upgraded to Windows 7 I don't get my .NET COM objects to work anymore.

My COM object is as easy 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.");
        }

    }
}



namespac开发者_开发知识库e Crap
{
    [Guid("1234685b-6e22-49ef-a046-74e187ed0d21")]
    public interface IMyClass
    {

    }
}

assembly is marked ComVisible as well.

I register the assembly using

regasm /codebase /tlb "path"

registers successfully (admin mode). I tried regasm 32 and 64bit. Both time I get the error

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

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

fuslogvw doesn't give me any hints either. That COM object works perfectly on my Vista 32 Bit machine.

I don't understand why I haven't been able to google a solution for that problem.. am I really the only person that ever got into that problem?

Looking at OleView I see my object is registered successfully. I am able to create other COM objects as well.. it only does not work with my own ones.

Thank you, Kevin

---

I'm not a C# person, but here is a sample that I converted from VB.net. Note, I had to ensure I had a single namespace at the project level, then this class in VB projects. I understand that's 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 I'm concerned about COM, I always check in the registry first to ensure the appropriate entries have been created. I've found that versioning and MSI installation cause issues, expecially uninstalling (doesn't clean up the registry) or re-installed and MSI with .net COM objects that overwrites an existing COM entry causes all sorts of hassles.

I generally find that you have to be carefull about x64 vs x32 build .net DLLs. For instance you might have to explicitly reference C:\Windows\SysWow64\ or C:\Windows\System32\ editions of the VBS engine.

Finally if your using VBS in a ASP web site on a x64 server with a x32 COM .net component, then you will need to ensure the IIS 7 Application Pool advanced option Is 32 bit application is correctly set True/False.

---

Thanks! Did not know there were 2 registries I have to take care of.. was about time to switch to Win7 64 bit I guess :)

Thank you.

For everybody else that runs into the same problem: wscript (the client that executes vbs files usually) is executed in 64bit mode => RegAsm 64bit is to be used

Other common clients like Excel are executed in 32bit mode => RegAsm 32bit is to be used.

Visual Studio is executed in 32bit => Register for COM interop only registers the COM object in 32bit registry.

The only thing I now have to figure out is how to make sure that VS Setup registers both versions