Partager via

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

  • Article

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

  • Anonymous
    May 28, 2004
    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.
  • Anonymous
    May 28, 2004
    The comment has been removed
  • Anonymous
    May 29, 2004
    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.
  • Anonymous
    May 29, 2004
    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?
  • Anonymous
    June 01, 2004
    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.
  • Anonymous
    June 02, 2004
    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?
  • Anonymous
    June 02, 2004
    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".. ?
  • Anonymous
    April 02, 2008
    原来做过一个小的win程序操作Excel的被那些个参数搞的头晕晕的那么多Missing啊今天在Blog.Msdn.com看到关于VB和C#在office开发中的比较的讨论 http://blogs...