CODEWITHSUNDEEP
.net
Greg McGuffey
Greg McGuffey

Reputation: 3316

TypeLoadException in COM Library

I have a class library that has a class, MessageGroupInfo, that contains some string and bool properties. No methods. I use this class to pass info to a constructor of another class, MessageGrouper.

These are used by a COM visible class library that is an Add-in to another app. Both the add-in assembly and the class library use .NET 4 client targets.

When I call a method that uses MessageGrouper (and thus MessageGroupInfo), I get a TypeLoadException. It can't find MessageGroupInfo. I know it has resolved and loaded the class library because other code in that assembly is working just fine.

I setup a quick WinForm app to see if it had an issue, but it worked fine.

This problem originally occurred on a 64bit win7 box. It works fine on a XP 32bit box.

So, could this be a 64 bit thing or a COM-64bit thing? Is there some setting I'm missing? Not that otherwise the add-in works well, calling many other methods in the class library.

Thanks!

Upvotes: 0

Views: 74

Answers (2)

Greg McGuffey
Greg McGuffey

Reputation: 3316

Thanks to Hans, I figured out that the issue was .NET referencing an old DLL of the class library. The debugger was looking at the correct one (I.e. Intellisense could find the method), but that method wasn't actually in the DLL being referenced. I haven't figured out why this occurred, but the fix was to find all instanced of the DLL, delete them and rebuild. BAM. It worked. :D

Thanks Hans for pointing me in the correct direction!

Upvotes: 1

Jeffrey Hantin
Jeffrey Hantin

Reputation: 36494

It's likely to be a 64-bit thing. By default, .Net applications are built architecture-independent, which means they will be launched as 64-bit processes when on a 64-bit machine. A 64-bit process cannot load a 32-bit DLL, or vice versa.

I had this problem myself with an app containing a WebBrowser control that couldn't instantiate Flash player for this reason.

Just to complicate things further, there are two separate registry key trees for 32-bit and 64-bit COM classes; if your library is built architecture-independent it will likely get registered in the 64-bit tree when your native app is looking in the 32-bit tree.

Change the project's platform target setting to x86 to ensure that your code is always treated as 32-bit. (In Visual Studio, you'll find this on the project properties, Build tab.) Even with that setting, though, I'm not sure of what madness you'll run into trying to build an installer that deals with the details of 32 vs 64 bit registration. Visual Studio's installer projects may or may not do the right thing.

Upvotes: 0

Related Questions