Interop 2.0 vs. 1.1 Breaking Change

This isn't the most exciting adventure I'll write about but it seemed as though several people out there experienced this adventure so I thought I'd divulge my secret route to get through it alive.

Here is the super nasty and super helpful error message that I received at run-time:

Unable to cast COM object of type 'System.__ComObject' to class type 'SomeCompany.SomeProduct.Interop.SomeClass'. COM components that enter the CLR and do not support IProvideClassInfo or that do not have any interop assembly registered will be wrapped in the __ComObject type. Instances of this type cannot be cast to any other class; however they can be cast to interfaces as long as the underlying COM component supports QueryInterface calls for the IID of the interface.

It was clear what I had to do.

OK, maybe it wasn't so clear what I had to do but thanks to doing a little reading between the lines at this post it became clear what I needed to do.

First of all, it appears that this happens when you convert a 1.1 project to a 2.0 (or higher) project and the project has a reference to a COM DLL via interop.

The solution is to drop your reference to the COM DLL and then re-add it.

Next go to the lines where you are experiencing the errors and make a tiny change by deleting the "Class" suffix off of the type names in your variable declarations. For example, my VB.net 1.1 code looked like this and would not run in 2.0:

Dim objFdfAcX As FDFACXLib.FdfAppClass

Dim objFdf As FDFACXLib.FdfDocClass

I simply dropped the "Class" suffix and the following 2 lines ran just fine:

Dim objFdfAcX As FDFACXLib.FdfApp

Dim objFdf As FDFACXLib.FdfDoc

The great thing about this little adventure is that it reaffirmed what my friends have told me for decades, "You've got too much class." Now, I finally know what they were talking about.

Happy coding.