Yesterday I visited a local launch of the new Office System. It had a developer track with a very nice talk on creating applications for the new Office suite. The most flexible way to do that is using the Office tools for Visual Studio. What these tools actually do is provide a COM interop bridge to the classical automation object model of Office. Which is nice because that is a rich model. But there is a little downside to it. Most methods of the Office object have loads of parameters, a count of 11 is not unusual. Which would mean that programming such an object with C# means having to provide something for every one of those parameters. A Type.Missing will do, but nevertheless... VB.NET knows how to work with named parameters making it it a little easier to program your Office object, just pass the parameters that do matter as a named parameter and forget about the rest. The speaker (Ernst Peter Tamminga) is a well known VB(A)(.NET) evangelist in the Netherlands, he was happy. Several C# afficionado's in the audience, like myself, were stung by a hornet. But we had no reply except wrapping the Office object up in a “usefull” assembly (with overloaded methods where needed) and target that assembly from our C# code.
Blog on,
Peter