When programming for Excel in C# (using the Excel 14.0 library), there are several interfaces that have the same name, but one has an underscore in front of the name. For instance:
_Workbook
Workbook
_Worksheet
Worksheet
_Application
Application
etc
What is the reason behind this and what does the underscore signify? Most of the sample code I'm seeing is calling for the interface name that has the underscore.
Take a look into MSDN. For example Workbook is
[GuidAttribute("000208DA-0000-0000-C000-000000000046")]
public interface Workbook : _Workbook,
WorkbookEvents_Event
So Workbook extends _Workbook with methods from WorkbookEvents_Event, which means that many event handlers are added - that's all.
The rest interfaces are similar.
It is an old convention in OLE Automation, it indicates that the interface type should be hidden from the programmer. Common in scripting languages and languages like VB6 and VBA, you use the default interface on the coclass instead of the interface type.
To expand on Garath's observation that Workbook is a combination of _Workbook and WorkbookEvents_Event.
Basically, the _Workbook interface is what Excel implements, and the WorkbookEvents_Event interface are the events it raises.
In COM, WorkbookEvents_Event is a source interface, and actually defines method signatures for the client to register as an event sink (aka, event handler). The Workbook interface is the actual coclass (COM class) which ties it together - this class exposes _Workbook methods, and is the source of WorkbookEvents_Event.
In COM, the _Workbook interface would be returned from a call to IUnknown::QueryInterface (which is how you'd interact with Excel), and WorkbookEvents_Event would be returned from IConnectionPoint::GetConnectionInterface. In turn, to subscribe to Workbook's "events" (connection points in COM speak), you'd pass an implementation of WorkbookEvents_Event to IConnectionPoint::Advise for Excel to call when events happen.
As it gets translated to .NET, these source interfaces largely lose their meaning and become an implementation detail. Strongly typed delegates simplify things, and COM interop automates any of the rote interface magic.
In most cases, just using the coclass interface for Office interop (Workbook) is sufficient and closest to the .NET model. NB, however, that I've seen other vendors recommend the use of the actual wrapper (eg., WorkbookClass) instead of the generated interface (Workbook) for future versioning. To be honest, I've (thankfully) never had to think through the ramifications of going either way.
Oh, and the underscore is mainly a convention and a handy way of generating a COM interface name given a class name. VB6 would create COM interfaces for classes with that convention (eg., if you had a class named Workbook, it'd export a COM interface _Workbook) since it was an invalid VB6 name. Generally, a leading underscore is either an invalid identifier (VB6) or reserved (C++) so it makes for handy auto-generated names.
In programming, underscores at the beginning or end of accessors generally indicate private, crusty APIs.