What is the difference between _Application and Application

Question

Why is it that to use Word you define a variable like this:

Dim Word As Microsoft.Office.Interop.Word._Application

OR

Microsoft.Office.Interop.Word._Application Word;

Then set it like this:

Word = New Microsoft.Office.Interop.Word.Application

OR

Word = new Microsoft.Office.Interop.Word.Application();

Whats the difference between Application and _Application

I suspect one may be a class and the other an interface or one may be public and the other private but that still makes no sense to me.

I was hoping someone can explain it to me. The more details the better.

Answer 1

Both are interfaces and the Application interface inherits from the _Application interface (together with the ApplicationEvents4_Event interface).

So when to use what? The difference is explained in MSDN (emphasis added):

Application interface:

[GuidAttribute("00020970-0000-0000-C000-000000000046")]
public interface Application : _Application, 
    ApplicationEvents4_Event

This is a .NET interface derived from a COM coclass that is required by managed code for interoperability with the corresponding COM object. Use this derived interface to access all method, property, and event members of the COM object. However, if a method or event you want to use shares the same name under the same COM object, cast to the corresponding primary interface to call the method, and cast to the latest events interface to connect to the event. Refer to this topic for information about the COM object.

_Application interface:

[TypeLibType(4304)]
[Guid("00020970-0000-0000-C000-000000000046")]
[ComImport]
public interface _Application  { ... }

This is a primary interface in a COM coclass that is required by managed code for interoperability with the corresponding COM object. Use this primary interface only when the method you want to use shares the same name as an event of the COM object; in this case, cast to this interface to call the method, and cast to the latest events interface to connect to the event. Otherwise, use the .NET interface that is derived from the COM coclass to access methods, properties, and events of the COM object.

Practical consequences

In short: Use Application and not _Application in your code, unless you have to because there is an ambiguity between a method name and an event name.

Such an ambiguity exists for example between the Application.Quit event (fired when the application quits) and the Application.Quit(ref Object SaveChanges, ref Object OriginalFormat, ref Object RouteDocument) method (exits the application, when called).

In order to call the method, you could simply write (e.g. to quit without prompting to save changes):

Application.Quit(false);

However, this might give you the following compiler warning:

Warning 3 Ambiguity between method 'Microsoft.Office.Interop.Word._Application.Quit(ref object, ref object, ref object)' and non-method 'Microsoft.Office.Interop.Word.ApplicationEvents4_Event.Quit'. Using method group.

To avoid the warning, you can cast the application object to the _Application interface:

((_Application)Application).Quit(false); 

If you you want to subscribe to the event, you need to cast the application object to the appropriate event interface:

((ApplicationEvents4_Event)Application).Quit += OnApplicationQuit;

private void OnApplicationQuit()
{
    // handle event here
}

Answer 2

It is kind of a long story, at break-neck speed. COM uses a hyper-pure interface-based paradigm. A client app only ever makes calls on interface members, the "coclass" that implements the interface is completely hidden from view. All that is exposed is the guid of the coclass, the CLSID. That is passed to the universal CoCreateInstance() factory function, it returns the interface you asked for. This isolation is the primary reason that COM servers can be written in any language, none of its implementation details are visible so can never be incompatible with whatever language you use.

Working with interfaces was however a problem with early VB versions, unlike VB.NET they did not have any support for interfaces. So their runtime support tricked it out and makes it look like you are working with a class. Named Application in this case. The members of that class are the members of the default interface, _Application in this case. Any connection points from the default source interface are added as events.

The leading underscore in _Application is a trick as well, it tells type library browsers to hide the interface. Something that the Object Browser in Visual Studio does not do, perhaps one reason you are asking this question. One thing the trickery can't accomplish is dealing with a coclass that implements multiple interfaces. But taken note of by the type designer, he made sure to give the coclass only one default interface and one source interface.

Similar trickery was necessary to give .NET programmers the same kind of api, ensuring that they too could use Application and get their code easily ported. This is done by the type library importer (Tlbimp), it synthesizes an extra interface with the same name as the coclass, all of its members are exactly the same as the default interfaces.

This is an interface, the VB.NET and C# compilers allow you to create an instance of it. Very unlike what you can do with a normal interface. The importer also synthesizes a class, same name as the coclass with "Class" appended. So ApplicationClass here. It implements all of the interfaces that the coclass implements. You have no practical use for it in VB.NET and you should avoid it since the very desirable "Embed Interop Types" feature doesn't support embedding it. But you may want to use it in a language like F# or a language that was ported to .NET but doesn't support interfaces.

Long story short, _Application is the actual interface that came from the type library. But you ought to favor the synthesized Application, best match with all code samples you'll ever encounter.