Wednesday, October 22, 2008

Fun with COM interop

So I have a C# object which exposes a COM interface through interop, and it was working. Then I did something, and when I went to reload it, it said the component was not registered. I confirmed that the ProgID was in the registry, and everything appeared to be good.

... It turns out that if the constructor for an object which is being constructed for a COM object instantiation throws an exception, the CoCreateInstance call will return that the component is not registered. This is not normally a problem with native C++ COM objects, since they run the constructor code as part of the registration process, so you'd catch the error earlier. However, C# COM object apparently do not, and the error coming from COM is very misleading.

Just an interesting tidbit for COM interop.

Monday, October 6, 2008

Bizarre error of the day

So I'm playing with compiling something which is C++/CLI using /clr, and ran across an error while trying to run:
'Could not load file or assembly' of my exe itself!

So to make a long story short, after some research, it turns out that:
- The .NET framework cannot load assemblies which have more than 65k global symbols defined
- Every static string in the code apparently is assigned its own global symbol when compiling with /clr

The solution, equally bizarre, is to enable string pooling for the Debug build of the exe. This reduces the amount of static strings dramatically, which allows the assembly to load, and the program to run. Talk about a random issue.

Oh, and obligatory "yeah, C++/CLI is ready for real world apps...".