ApplicationClass Needn't Be Avoided

Geoff Darst--an engineer on our team--sent this to me a while back and I think it would be good to pass it on. I still think in general people avoid using ApplicationClass because it makes your code look like the VBA and VB6 code everyone is familiar with.  But Geoff points out that there is no need to explicitly avoid ApplicationClass.  You may need to revisit the blog post he refers to in order to get the context where his comments make sense.

I just stumbled on your blog post talking about the types in the Office PIAS (https://blogs.msdn.com/eric_carter/archive/2004/05/06/127698.aspx) and I wanted to clear up a misconception you are spreading in your post.  The issue has to do with the way tlbimp deals with CoClasses.  As you know, for CoClass such as Application, it will create an interface named Application and a class called ApplicationClass.  When you suggest users should disregard ApplicationClass in favor of Application, you are offering some potentially bad advice. 

The class interface (i.e. Application) exists solely to match VB6 behavior where you could new up a CoClass and not have to “pick” an interface (by casting).  IOW with COM CoClasses you had to attribute a default interface in the typelib.  A language like VB would grok the typelib for the default and handle doing the QI under the covers for you so you could just new up the type without worrying about interface.  So back to .Net.   The class interface consists of *only* the default interface methods, plus any event hookups and the GUID.  The class on the other hand, (i.e. ApplicationClass) implements the methods on *every* interface (plus event hookups,  the GUID and the ClassInterfaceAttribute).  In general, you would want to use the class interface because that way you get full access to methods without having to cast.  The class interface is great for porting VB6 code, but it isn’t really the best choice outside of that.