Looking at the Office XP Primary Interop Assemblies on MSDN yesterday, I thought I'd do the "sample walkthrough" in the "Working with..." document. It said to build a Windows Forms app using VB in VS.NET, but I clicked without thinking and started a C# project instead. The code to paste in was only about a dozen lines long, so I thought "What the heck. I'll just convert it to C# while typing it in."
The first problem I ran into was the presence of 14 (count 'em) default parameters on the Excel application Open method, which the C# compiler insisted it needed. Although 14 nulls compiled successfully, it raised a runtime error. So I started a second project, this time in VB.NET, built the sample, and looked at the resulting IL with ILDASM. It turns out that 14 System.Reflection.Missing.Value parameters were needed.
The second problem was thornier. The VB code referenced objRange.Cells(intRow, intCell).value, where objRange was a reference to a Range object. The problem was that the interop libraries don't know about any value property. So it was back to ILDASM and the VB version. The VB.NET code gets at the value property through the static method Microsoft.VisualBasic.CompilerServices.LateBinding.LateGet. Okay, this is the Common Language Runtime, so choice of language shouldn't matter, right? Can I call this method in C#? Looking around, I found it in the assembly Microsoft.VisualBasic.dll. So I added a reference, called the method and, wonder of wonders, it worked.
I also noticed that the VB IL was using some other helper methods from the Microsoft.VisualBasic.CompilerServices namespace. Rather than figure them out, I decided to start up my favorite .NET decompiler and generate C# source from the compiled VB.NET executable. Here is the cleaned-up C# code side-by-side with the original VB.
3:10:18 PM 
|
|
