Question

Every time I see an example of office Automation using.NET, the language used is VB.NET.

Is this because originally, automating Office apps like Excel could only be done using VB Script in a macro and the same people that wrote these macros naturally tend to gravitate to VB.NET or is there a reason not to use C# for Office Automation?

It appears as though I can instantiate the Excel class from C# the way I would use CreateObject from VB.NET.

excel = Type.GetTypeFromProgID("Excel.Application");

If you had to write a .NET program using Excel Automation, what language would you use and is there any reason to avoid C# other than maybe there are ore VB.NET examples?

Edit:

I was thinking of writing the code with an explicit reference to the Microsoft Excel Object library and explicit instantiation of an Excel class Application object and then, after the program is essentially tested, modifying the code to use late binding to allow the app to run with different versions of Excel.

Will the code be radically different?

For example, using early binding I can do this…

var excel2  = new Microsoft.Office.Interop.Excel.Application();
excel2.Visible = true;

In late biding, will I be forced to use radically different code like this?

excel = Type.GetTypeFromProgID("Excel.Application");
excel.InvokeMember("Visible", BindingFlags.SetProperty, null, excelObject, parameter);

Answer 1

I’ve used both successfully, though there are more code examples available for VB.NET.

One difference I can think of immediately is that the API methods seem to contain gajillions of optional method parameters, which don’t exist in C# < 4, so you’ll find yourself doing things like:

object missing = Type.Missing;
Excel.Application xl = new Excel.Application();
xl.Workbooks.Open(fileName, 0, true, 5, "", "", true, 
            Excel.XlPlatform.xlWindows, missing, missing, missing, 
            missing, missing, missing, missing);

Instead of just this in VB.NET:

Dim xl As New Excel.Application()
xl.Workbooks.Open(fileName, 0, True, 5, "", "", true, Excel.XlPlatform.xlWindows)

Some of the syntactical sugar that VB.NET provides goes a long way with the conciseness of writing application that use the OLE Automation libraries or interop assemblies.

EDIT: As for early- vs. late-binding, I can’t say that I have any experience with late-binding. This article talks about an approach to safely implement late-binding for multiple versions of an office application.

A quote from the article:

…you can start developing your add-in using interops for the highest version of the Office application. When this is done, you can replace early-binding calls to the features introduced in this Office version with late binding calls and make sure these calls work. Then you can replace the interop assemblies referenced by your project with the interop for a previous version of the application and reiterate the procedure. Kind of refactoring. Whether this approach is useful or not, this is you who decides