Office 2007 VSTA scarlet pimpernel

They seek him here, they seek him there, they seek him everywhere. (now available as a ringtone!)

I thought I’d have a tinker with VSTA in Infopath 2007. So I fired up a clean Win XP VPC and installed Office 2007. (great install btw – one click, leave for half an hour job done – not like VS which needs a prod every few minutes)

(Bear in mind the inclusion of VSTA in Office 2007 was a much trumpeted feature.)

I click around trying to remember which one of the apps I’ve never used has VSTA, Google a bit follow some instructions and come to a dead end.

‘Feature not available’ the installer says – hmm. More Googling gets me here. In summary to use VSTA you need .net framework 2.0 (or higher presumably) and the MSXML security hole.

So I then have to go and download these 2 components install them on the VPC (which meant a whole additions/networking dance (3 reboots I think)) then rerun the Office installer (glad I left the temp install files on there) and now I think I’m in business. I havent had chance to check because I’m trying to get all the VPCs built for next week – I could have done without this multi hour diversion. And I don’t want to use up my 20 odd uses and end up locked out for the conf ;-).

But the big question is, if Office 2007 has a dependency on .net framework 2.0 for some of its functionality shouldn’t it distribute the framework as part of the Office install? (at least on those versions that include VSTA)?

I know Office and VS are on different release schedules but really, what chance is there of convergence and adoption if its this painful to even try the thing out? (never mind deploy a solution to 20,000 desktops)

In a way I think this hidden/missing/unexpected dependency thing sums up the .net experience. I can’t help wondering if the Office team are trying to avoid getting sucked into it, if so I can’t blame them. But just fess up and tell us to use C++ native code then we’ll know. (Excel SDK in C/C++?). (Oh and please expose all the new stuff to the C API too – ta)

Cheers

Simon

[Stop press – We have VSTA – not a right lot of use as I know completely nothing about the Infopath object model, but still its there.]

Advertisements

12 Responses to “Office 2007 VSTA scarlet pimpernel”

  1. tfsjohan Says:

    I agree Simon! If .net framework, the Office PIA:s and the VSTO Runtime was part of the Office installation I think alot(!) more developer would switch to VSTO.

    Now deployed is a real pain in the butt and these dependencies and the CAS is to blame for that. I understand the need for CAS, but I don’t understand why I must follow a 10 page walkthrough just to deploy a VSTO solution.

    Even though I really love .net, it’s not always a pleasent experience working with VSTO. COM Interop mess upp the debugger and exceptions, the Office object modell uses alot of ByRef-parameters and optional parameters which is really ugly in C#. Ever tried to use the Range.Address-“property” in C#? Well, now it’s a method called get_Address and has like five or six parameters you never know how to use… Yikes.. And have you tried to use the Protect method of a workbook? Yikes again!

    Regarding InfoPath.. With VSTA you atleast get IntelliSense, which you don’t when you use JavaScript…

    // Johan

  2. Stephane Rodriguez Says:

    “the Office object modell uses alot of ByRef-parameters and optional parameters which is really ugly in C#. Ever tried to use the Range.Address-”property” in C#?”

    Use VB.NET for interop calls, and C# for everything else then.

  3. Simon Says:

    Yeah I’ve mentioned before, working with Excel with C# feels a lot like swimming against the tide. At every opportunity they conspire to make it harder than it needs to be.
    I have never understood why the overrides are not art of the PIAs so at least you can do without all those Missings.
    MS answer seems to be as Stephane says – use Vb.net.

  4. tfsjohan Says:

    Exactly! Why if they’ve taken the time and effort to create the PIA:s, why not use overload for all optional parameters? How hard could it be compared to all the other work they’ve done.

    They have done overload for some methods, implemented new events and even new members on some objects, like to bookmark or named range host controls, so why not all of it?

    I guess VB.Net is the only practical solution, but still, why doesn’t it work with the preferred .net language?

    I really like C# and don’t really wan’t to learn VB.Net, but I guess I just have to.

    // Johan

  5. Dennis Wallentin Says:

    In general I believe we all need to be aware of that most stuff that comes out of the Redmont factory target enterprises.

    Why don’t create an Excel library which is used whenever you need to access the Excel Object model in C#? For me it looks like the only workable way.

    After all, for instance Range.get_Value() and Range.get_Address are disasters in this context.

    Kind regards,
    Dennis

  6. Stephane Rodriguez Says:

    “MS answer seems to be as Stephane says – use Vb.net.”

    It’s not exactly what I said. My answer is more along the line of “use VB.NET *only* for interop calls, and your preferred .NET programming language for everything else in your project”.

    Since Visual Studio 2005 projects can combine both languages in the same project, I think it’s even easier. And that’s one benefit of Visual Studio 2005 over 2003. (of course, one could just as well create a separate assembly library in VB.NET, and make it a dependency of assemblies written in other programming languages).

  7. SPG Says:

    Simon.
    How’s it going? I’m cool.
    A couple of things…

    The first one is slightly off topic but kinda important so I thought you should all know. There appears to be a bit of a problem that occurs on developers machines when building using this combo: VS2008 + VSTO + Office 2007. The PIA (Primary Interops) are the root of the problem. The Office 2007 install can not be properly/completely removed from the development machine. You are advised to consider VMs for this combo.
    Google it for all the gory details. Basically if you compile this combo on a machine then it affects that machine. Apparently MS did not fully consider the Clean uninstall of Office 2007 – fancy that. I have Office 2003 on my main machine and everything else in VMs.

    I write in both C# and VB. I got over the whole C trap that most developers fall into, I choose the best tool for the job. When writing VB I avoid the VB specific namespaces (e.g. My.Computer.FileSystem etc) and use the general namespaces, in this case System.IO. Its not the language that takes time to learn – its the object model. I do the same objects in either C# or VB. C# does not support optional parameters hence the need for all those missing parameters – remember VSTO was derived from the VBA object model, just look at the syntax in VSTO VB compared to VBA – its exactly the same. Overloads won’t work in C# take the VBA Union method as an example or the Application.Run method with so many arguments you need an overload for each increment. Application.Run has 30 parameters so you will need 30 overloads. VB also has excellent support for XML (Linq).
    And finally (the thing that matters the most)
    Tell a corporate type that you are doing Excel 2003 (or 2007) with VS, VSTO and C# and he will go huh.
    Tell him that you are doing Excel 2003 (or 2007) with VS and VB and he will have some idea – you don’t even need to mention VSTO :) you just say oh VS includes Office now.

    Conclusion.
    VB for anything VSTO related, C# for everything else (or maybe just for a bit of variety). I will no doubt meet a lot of plonkers in the future who will stroll around and say casually like – oh I do C# (i.e. he thinks hes a bit of a smartarse) well my standard response will be – well I do both C# and VB and why on earth are you trying to write C# in VSTO?

    Who do you think will get the job done best?

    Cheers

  8. Ross Says:

    Ha!
    Hopefully I will get my ass into gear and make a post tomorrow that i started to day, much along the same line Excel/com .Net = pain in the posterior

  9. Ross Says:

    P.S seriously stating to think about Delphi…

  10. Simon Says:

    Anyone know if (/how hard it is) to write COM add-ins in Delphi? I know you can do xlls ok.
    I’ve had a skim around and COM looks OK in theory – if so I reckon that makes Delphi a very realistic choice.
    There is a great community around Delphi and it does produce real standalone applications. Which even VS2005 C++ doesn’t from what Stephane was saying!
    The Delphi Turbo things are a free download right? might take a look after the conf.

    Steve I know about the 30 overloads (for almost everything)- thats why I think MS should write them not us! That doesn’t fix the other issues though. I think its a choice between C# and targeting Excel as doing both makes little sense. And maybe this is VBs future destiny as the object model code of choice for Office?

  11. Ross Says:

    Si,
    Not sure about com, athough Addin Express do a thighy for delphi com addins, can’t see it being that hard? (famous last words!)
    So far i have only looked brifely, but saw a example for delhi xll, which looked ok.

    It’s free, but the paid for version allows you to add componets, theres also a c++ comp/ide and wait for it a .Net one too!!!!!!

  12. Johan Nordberg Says:

    30 overloads doesn’t bother me so much. And if that’s so ugly, why not have a object[] as an argument? Take Union for instance, most of the you just use two parameters. Why not have over loaded for Union(Excel.Range range1, Excel.Range range2) and then a Union(Excel.Range[] rangeCollection) for all the others.

    Really, how often do you have 30 arguments to the Range method in VBA? How often do you use more than two? For me, recursive functions is more practical.

    // Johan

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: