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

也有人和我一样抱怨为何C#中操作office产品的方法有那么多的参数

武眉博 — Thu, 03 Apr 2008 14:24:28 GMT

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

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

Joku — Thu, 03 Jun 2004 12:08:00 GMT

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".. ?

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

Cyrus Najmabadi — Thu, 03 Jun 2004 07:41:00 GMT

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?

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

Joku — Wed, 02 Jun 2004 13:33:00 GMT

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.

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

Cyrus Najmabadi — Sat, 29 May 2004 20:45:00 GMT

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?

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

Joku — Sat, 29 May 2004 16:44:00 GMT

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.

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

Cyrus Najmabadi — Fri, 28 May 2004 22:34:00 GMT

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.

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

Scot Boyd — Fri, 28 May 2004 22:29:00 GMT

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.