how to call a C# dll from unmanaged c++ using IDispatch?

Answer 1

I've had a similar problem before. I wasn't calling C# from C++, but the concept is the same.

I had to load a .NET dll into a host application via COM, which looks like what you are trying to do. The problem was the host application (in your case excel) was loading the .NET runtime 1.1. Our dll was compiled for .NET 2.0.

It could be that Excel 2003 is loading the 1.1 runtime and 2007 loads a more recent version. Check out this forum this: Excel selects wrong .NET runtime.

You could also test this by using MSBee to target the 1.1 runtime and then try load your dll in Excel 2003.

Answer 2

I'm not a C++ coder, so I can't comment on that part, but to answer it from the C# side:

"I'm I doing something wrong in the way in which I declare my C# dll that is causing me problems in excel 2003?"

No, your attribute usage looks exactly correct. Well done.

"Just as it is now, can my C# dll be considered an ActiveX object?"

By compiling with the attributes you show and then registering via RegAsm, you have created and properly exposed your assembly to COM, which is what you want. (The term "ActiveX" is usually used in reference to COM controls, and your class is not a control.)

"How can I call my C# dll in another way from c++? like using IDIspatch for example."

You are using the [InterfaceType(ComInterfaceType.InterfaceIsDual)] attribute, which means that the interface is exposed to both early binding and late binding via IDispatch.

In short, I don't know what's wrong here, so I would try dequadin's idea to check that the .NET Framework version being loaded is at or above the framework on which you are building.

If that isn't it, the only other thing I can think of is the fact that you are getting a straight crash, without a recoverable error, suggests to me that there could be some sort of mis-alignment between the registered interface vs. the interface on which the caller was compiled. This can happen because the GUID does not change if you change the interface -- you have explicitly set the GUID via an attribute -- so if the interface changes at all without everything being re-built and re-registered from bottom-to-top, all hell breaks loose. Therefore, if you changed your interface in any way, then you need to re-build the C# assembly, re-register with RegAsm, and then re-compile your C++ add-in that is referencing it.

This is just my best guess though. And does not explain the Excel 2003 vs. 2007 issue if you are using the same exact assembly for each. In short, it's hard to know what's wrong because your C# code looks 100% clean.

-- Mike