5

I keep hearing that c# is "better" than vb... but as far as I can see, aside from syntactical differences, both compile down to the same IL. I've found some good articles by googling that explain what the differences are between the two and so I feel comfortable in "diffusing" conversations between developers arguing over vb / c#. =)

But I did read an article that said vb.net 2005 had better support for com interop stuff. But i'm wondering if this is still the case? This is of interest to me because we are in the middle of redesigning an old vb6 app that communicates with some older COM components.

Does anyone have recent experience with .NET and COM interop? Thanks.

dot
  • 531
  • 4
  • 12
  • 1
    I take issue with everyone saying "it compiles to the same IL". It doesn't. VB and C# compile to the same IL *language*, but considerably different IL output. – Sam Axe Mar 11 '13 at 23:41

2 Answers2

15

Before .NET 4.0, VB.NET had a slight advantage over C# when calling COM interop code. This was especially true for code, such as the Office programmability model which, as mortalapeman notes, makes use of COM's support for optional parameters. This API often exposed methods with 10, 15 or more parameters (ugh!), all of which were ref params, which in C# had to be specified as references to Missing.Value. This was a pain.

It's important to note, though, that while this was common when calling Office code, I never really encountered it anywhere else. Most COM APIs I worked with were a lot more straightforward, and could be called from C# with little hassle.

However, in .NET 4.0, even this small problem has been corrected. For general purpose COM APIs, you can use the dynamic keyword to call late-bound code without the strong type checking C# usually demands, and thus call COM APIs without a hitch. Check out this article on general usages of dynamic, and this one specifically for working with COM objects.

If you're planning on using this to interop with Office components, C# 4.0 offers an even simpler solution. Check out this MSDN article on Office's optional parameters:

Visual C# enables you to omit optional ref parameters only for methods of interfaces, not classes.

[...]

If you want to write code that omits optional ref parameters of a method in the ThisDocument class, you can alternatively call the same method on the Microsoft.Office.Interop.Word.Document object returned by the InnerObject property, and omit the parameters from that method. You can do this because Microsoft.Office.Interop.Word.Document is an interface, rather than a class.

So instead of calling myWordDoc.CheckSpelling() with 12 (count'em, 12!) pointless optional parameters, you can call myWordDoc.InnerObject.CheckSpelling(IgnoreUpperCase: true), clean and neat.

Avner Shahar-Kashtan
  • 9,166
  • 3
  • 29
  • 37
  • Optional parameters have nothing to do with .Net 4.0 (the library and runtime), they are a feature of C# 4.0 (the language). – svick Jan 29 '13 at 21:09
  • While this is technically true, C# 4.0 was introduced with .NET 4.0, and I treat them both as a package, even if some of it (the C# 4.0 language) can be used even when compiling against older .NET Framework versions. – Avner Shahar-Kashtan Jan 29 '13 at 21:12
  • Well, I think you should be precise when you're explaining something to others. And the fact is that .Net and C# are separate (though closely related). Also, you mentioned .Net 4.0 specifically when talking about optional parameters, I didn't say anything about `dynamic`. – svick Jan 29 '13 at 21:18
  • I accept the correction (and edited accordingly) but in general I'll take clarity over completeness any day. :) – Avner Shahar-Kashtan Jan 29 '13 at 21:22
3

The only experience I have with COM interop is with C# and interacting with Excel in .NET 3.5. When calling interop functions from C#, you had to supply every single argument in the function call with a reference or value type. If you were not using the function argument, you had to use System.Type.Missing.Value in its place. However, if you were using VB, the unused arguments did not need to be supplied. This link contains both C# and VB code examples that show you how much of a difference it makes.

Microsoft has changed their COM api for Excel since .NET 3.5 to make calling these functions less verbose so it is not as bad as it used to be. A reason that one may have chosen VB over C# in the past is probably due to VB support for supplying all the missing arguments for you.

mortalapeman
  • 1,613
  • 9
  • 20