Write an Excel VBA macro in VB.NET or C #, first with early binding, then late

Question

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

This is because initially automation of Office applications, such as Excel, could only be performed using VB Script in a macro, and the same people who wrote these macros naturally tend to gravitate to VB.NET or there is a reason not to use C # to automate Office?

It seems I can create an instance of an Excel class from C # the way I would use CreateObject from VB.NET.

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

If you needed to write a .NET program using Excel Automation, what language would you use and are there any reasons to avoid C #, except maybe there are examples of VB.NET ores?

Edit:

I was thinking of writing code with an explicit link to the Microsoft Excel object library and explicitly instantiating an application object of the Excel class, and then, after the program was mostly tested, changing the code to use late binding to allow the application 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; 

Lately, 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 have used both options successfully, although more code examples are available for VB.NET.

One difference that I can think of right away is that the API methods seem to contain gajillions of optional method parameters that do not exist in C # 4, so you will find that you are 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, in VB.NET:

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

Some of the syntactic sugar that VB.NET provides is of great importance with respect to the conciseness of writing an application using the OLE Automation libraries or the interop assembly.

EDIT . Regarding early or late binding, I cannot say that I have experience with late binding. This article talks about an approach to securely implementing late binding for multiple versions of an office application.

Quote from the article :

... you can start developing your add-in with intermediate devices for the highest version of the Office application. When this is done, you can replace the calls with early binding with the functions introduced in this version of Office with the late connections and make sure that these calls work. You can then replace the interop assemblies referenced by your project with interop for the previous version of the application and repeat the procedure. Type of refactoring. Whether this approach is useful or not is up to you.