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.

  • 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
    Commented Mar 11, 2013 at 23:41

2 Answers 2


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.

  • 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
    Commented Jan 29, 2013 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. Commented Jan 29, 2013 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
    Commented Jan 29, 2013 at 21:18
  • I accept the correction (and edited accordingly) but in general I'll take clarity over completeness any day. :) Commented Jan 29, 2013 at 21:22

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.