C# vs. VB for Office development (part 1/?)


I’m at a Tech-Ed cabana session entitled “VB.Net vs. C# for Office development with Visual Studio .NET”. It’s going over a few reasons why it’s nicer to use VB for developing for office.

The first version that is mentioned is that many methods in office take long number of parameters (the speaker just mentioned 30), where almost all of these parameters are optional. In VB this is simple since it supports optional parameters and will substitute Type.Missing for all the optional parameters. So in excel you can do something like:

Document d = Word.Documents.Open(fileName, ReadOnly:=True)

whereas in C# you’d have:

Document d = Word.Documents.Open(fileName, Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing,
                                 Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing, 
                                 Type.Missing, Type.Missing, Type.Missing, true, Type.Missing, 
                                 Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing, 
                                 Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing, 
                                 Type.Missing, Type.Missing, Type.Missing, Type.Missing);

Yuck. Really ugly in C#. My question is, “why were the office APIs designed to have methods that take 30 parameters? Why isn’t there some nice structure that encapsulates all that state into something reasonable. Something like:

OpenFileArgs args = new OpenFileReadonly(fileName);
Document d = Word.Documents.Open(args);

i.e. OpenFileArgs encapsulates all that amazing amount of state. And, for convenience I can do things like subclassing that will set up things (like readonlyness) automatically. It’s much more readable and doesn’t require these UBER methods that carry around so much baggage (hidden or not) with them.

I really don’t like reading APIs that have these sorts of methods as I find them incredibly confusing.


Comments (8)

  1. Scot Boyd says:

    I would imagine the answer to your question is that the API is designed with VB as the intended language. You could probably find other APIs with operations that are easy to do in C# but hard in VB.

  2. Scot: The issue with that is that while that is true from the IDE perspective, it isn’t true from the documentation perspective. When I see a method with 30 parameters I just cringe. It’s incredibly unclear how it’s supposed to work, and generally there are complex rules that you need to know. For example:

    If you put in this parameter, then you must also set foo and bar and baz, but you must not set quux or ztesch.

    IMO, there is something usually very wrong with this sort of API and it should be take care of through subclassing. I.e. have a subclass with the 4 parameters that are required to be included together. Have another subclass with those other two that are tied together. Or, if you have the situation where there is some strange rules about which can work together, you instead have a class dedicated to understanding those rules. Clear methods on that class can make sure that it’s always initialized in a correct manner, and then you can then pass that encapsulated state object around appropriately.

  3. Joku says:

    Guess making and providing a "wrapper" to make the interfacing more nice would be a waste of resources. Hopefully something gets done at some point though.

  4. Joku: What do you mean by "guess making"? Why is making an interface nicer a waste of resources? If it makes developers more productive then I would consider a very good use of resources. What would you prefer to be done instead?

  5. Joku says:

    Sorry, _I_ guess that didn’t translate well to english..

    I meant that if "Longhorn Office" would have a better API, designed to be used like the framework set of classes, making that good would be better use of resources than working on some glued-on wrapper to the old "VB office API". This was my guess for why such wrapper haven’t been made and C# people are forced to the Word.Documents.Open(fileName, Type.Missing, Type.Missing,..) approach.

  6. Joku: Thanks for the responce. However, what’s the difference between a this "better longhorn api" and a "better api" that sits on top of the current one?

  7. Joku says:

    I suppose the Office team is already busy doing/designing some managed, truly .NET way to access Office (In Longhorn timeframe). Getting that API to be same with previous Office’s, before the "Longhorn Office" seems unrealistic. If someone was to now develop better managed way to access Office, with no co-operation with the Office team, that would certainly be incompatible and you’d have two managed ways, one for old Office and one for the LH Office 2006+.

    Certainly the Office team could do the new API compatible/wrap it so that current Offices work also, but in what timeframe? Perhaps such could be done as a preview API, so people can learn the LH Office 2006 way of programming Office with current Offices in XP, but not making a "final release", reserving the full right to do major changes before the LH Office 2006 in case there would be need for those. How many would use such "preview".. ?

  8. 武眉博 says:

    原来做过一个小的win程序操作Excel的被那些个参数搞的头晕晕的那么多Missing啊今天在Blog.Msdn.com看到关于VB和C#在office开发中的比较的讨论

    http://blogs