tlbimp: how does early binding work with “/noclassmembers”?

Question

I was playing about with tlbimp and I found the /noclassmembers option and I was like:

Ahhah! I bet that will break early binding!

But, much to my chagrin, everything still seemed to work fine even when using the interop assembly generated with this option. That is, there were no compilation issues (or apparent run-time issues on my test machine) when substituting in this new interop assembly.

So, what exactly does /noclassmembers do, and why would it not be desirable to always use this option?

Consider the following:

1. Apparently it is sometimes required to "avoid a TypeLoadError exception", and
2. The resulting interop assembly is smaller (it is only 3/4th the size in my case)

(Judging from the file sizes, the Visual Studio automatically generated interop assembly does not use this option.)

Thanks.

Answer 1

COM uses an interface based programming model. A coclass itself should not expose any members, it implements interfaces and exposes them with IUnknown::QueryInterface(). A type library does however not prevent a coclass from exposing its own members. Notable to happen with managed classes that are [ComVisible] and don't apply the [ClassInterface(ClassInterfaceType.None)] attribute. Those visible implementation details can be the source of the TypeLoadException.

So it is unsurprising that it doesn't cause any problems when you use the option, well-behaved client code will only use the exposed interfaces. You can use the oleview.exe SDK tool to take a look at the type library and see what is being exposed. Use File + View Typelib and pick the .tlb or .dll