VSTO strategy

Is VSTO the next VFP? (Visual FoxPro – a well regarded (database) technology recently end of lined by MS (as non-strategic?)). Access seemed to be going the same way, but somehow seems to have been rescued from the brink and in fact has gained a new lease of life. Which gives me some hope MS (well the Office team anyway) understand deployability.

VSTO seems like one of those range fillers that needs to be in a product range, but realistically no-one is expected to buy it or use it. (anyone know the proper name?)

In the countryside we have ‘Wildlife Motorways’, these are the linked up hedgerows, footpaths, bridleways and uncultivated land. Whilst these don’t particularly create a home for that much wildlife they allow wild animals to move around fairly freely.

I wonder if VSTO is this sort of a highway, to allow those millions [hehe] of VS devs who are desperate to leverage the richness of Office on the client (both of them!) to do trivial stuff with objects they will never understand. And to allow Office devs to tinker with .net in the hope they will join the great framework deployment/windows lock-in effort. And leave VBA forever of course. (A decent migration route for VBA code would have been more use!)

Or is VSTO more like a jab in boxing (well done Joe)? keep the opponent (who’s that? us? OpenOffice? Delphi?) on their back foot so they can’t counter attack, and also open up a chance to unleash the big guns (right hook/cross) (which is what? VSTA? Open Live office, or whatever its called? Excel services? Sharepoint?).

I think you would have to be pretty keen to deploy VSTO solutions for the next 12 months, till we can get a sense of its likely longevity. It may well be the killer app that drives Office dev for the next 10/15 years, or it might be retired through lack of interest in 12 months (remember those long gone exams).

I hope it gets rolled into Office, then I’ll be much more comfortable putting VSTO solutions into production.

In the meantime there is a ton of new stuff in Visual C++ 2008, mainly geared towards native code generation, and of course Excel, VBA, VB6, plain old C#, and a bit of OLAP continue to be widely business critical.

What do you think? too early to call? a proven lemon? good potential? already got some VSTO in production? Call again next year? VBA VBA VBA?

cheers

Simon

[I think this concludes my ‘Business of VSTO’ posts for a while (you’ll be pleased to hear)]

Advertisements

14 Responses to “VSTO strategy”

  1. Dennis Wallentin Says:

    Thanks for taking a longer break from ‘my baby’ .

    I like VSTO although I can agree about the business demands for it. In my opinion is too early to compare VSTO with VFP (How much development does MSFT do for VFP?)

    With ‘Orca’ we get a better deployment, a more integrated situation with VBA & VSTO. The process of creating templates where we can detach the code and the server side approach are excellent.

    I got the following VSTO solutions around:
    For 4 computers at company A with a document level application.
    For 16 computers at company B with a document level application based on a template where the code part is detached.

    Kind regards,
    Dennis

  2. SPG Says:

    Here is a repeat of my post to an older thread.

    ok, here goes.
    I guess I should say something now.
    I think everyone is missing the point.
    XML.
    Hit it from the client, use VBA.
    Hit it from the server, use .Net
    Think about it.
    The important thing is this:
    In Office 2003 you can save most apps as .xml
    In Office 2007 the file format is actually .xml
    The actual application can be abstracted away.
    The important thing is the underlying data format.
    Is this not obvious to anyone at all?
    p.s System.XML, System.XML.Schema, System.XML.etc in VS2005 is no walk in the park, :), lol.

  3. Simon Says:

    Steve
    traditional VBA is about extending or specialising the application, interactively with the user (at least the stuff I do has been). Personally Its Excels calc engine that I care about, rather than the file format.

    I have it the exact opposite to you, i care about the app and its object model, I don’t care about the underlying file format.

    XML is a big non event for me. I rarely unpicked BIFF files, I doubt I’ll need to ratch though the xml stuff for the sort of work that I do. Others may find this more useful, but I don’t see many ng posts needing to pick through .xls files. Its not that its not obvious, its that it not relevant (to the stuff I do).

    Clearly we do different systems.
    cheers
    Simon

  4. Biggus Dickus Says:

    “The important thing is the underlying data format.
    Is this not obvious to anyone at all?”

    Maybe you’re overstating this a bit ;-) …… ??

    I don’t give two h00ts about the file format – although I like to be able to import and export in any current format, including things like PDF and XML format.

    Excel is far more than just a data transfer tool in my books….

    Dick

  5. SPG Says:

    Yes, the response that I expected.

  6. Simon Says:

    Marcus posted this to the riding 2 horses post in response to Steve (i’m trying to keep th thread together over here):

    Hi SPG,

    Umm, I’ve got to disagree (respectfully so of course).

    Rather than XML, my experience (even today) has been flat file, typically CSV.

    To my surprise, I offered to supply an IT dept XML files for a data feed from an Access system. I thought I was helping to encourage a standard. Nope – too much effort for them to work with: could we have a flat file please. (Side Note: ADO 2.1 and greater has a nifty feature to persist a recordset in XML. Niiice).

    Most (almost all) of the data feeds I deal with in a corporate environment is flat file. Even the ones which have an XML interface translate this to and from a flat file during import/export into that system.

    Kind regards – Marcus

  7. Jon Peltier Says:

    “The important thing is the underlying data format.
    Is this not obvious to anyone at all?”

    To me what’s important is what can be done with the app. The underlying format is not particularly relevant. So I could hack into the XML of Office 2007, that’s nice, but it requires a new set of tools. I could as easily use automation to do the same with the BIFF files, not through direct manipulation of the file innards but trhough the object model. The client doesn’t care how it’s done, and there has been little reason to dig into alternatives.

  8. SPG Says:

    Marcus (Repost from the other thread)

    Good point re CSV, something I have previously considered in detail.
    Resistance is futile – they will be assimilated. (eventually :))
    When building a database much of my code revolves around the flat CSV files. Old legacy systems, mainframes etc are happy to spit out another flat file. The IT boys won’t pull finger on this without a good hard kick in the arse.
    1. Decide what you want and how you want it in XML
    2. Create an XSD Schema.
    3. Get the CSV data during the database build.
    4. Convert it to XML
    5. Validate the XML using the XSD.
    6. Send the CSV file back to the IT cowboys n times until they eventually get it right.
    7. Once you can successfully complete 4 & 5 all the time convert the validated XML back to CSV and upload.

    No SPECIFIC validation code is required for a PARTICULAR data feed.
    Its all done by the Schema. You just create a XSD for each data feed.

    This comment focuses on a relational database but it applies to Any type of data (structured and unstructured). the CSV issue will not occur with unstructured data as CSV can not be used to represent it i.e. the source files will already be in XML for any unstructured data.

    XML: the new CSV.
    XML: Machine To Machine.

  9. Stephane Rodriguez Says:

    SPG,

    Confusing statements between XML as format bits, and XML as data. You are pretty much following Microsoft own message confusion here.

    Also, you kind of miss something important : if you access the file format directly, you are losing all what Excel does for you.

    Here is a refresher for (and that’s just to get you started) : http://ooxmlisdefectivebydesign.blogspot.com/

  10. Simon Says:

    Nice article Stephane, thanks for the link.
    Reminds me why I prefer to automate Excel for any file activity. Also makes me appreciate the interop challenges.

  11. SPG Says:

    Started to read it and then got bored half way down.
    I particularly like how you sign off as an ‘expert’.
    Also the mandatory Bill Gates quote was a nice touch.
    Everyone trys to be a smartass.
    We shall see.

    I believe that there is only ONE XML standard (W3C).
    MS (OpenXML) and the other lot (ODF) are trying to build a standard on top of a standard (house of cards) to retain or grab market share.
    OpenXML (should be OfficeXML) is not a standard but a very detailed technical specification of a SCHEMA. (same goes for ODF)

    In a previous comment I said:
    From the client use VBA
    From the server access XML directly

  12. Simon Says:

    Steve
    If you start to look into Excel file formats in any depth you will bump into Stephanes work regularly.

    Anyway this is a VSTO strategy thread. Are you going to be doing VSTO dev soon, later, or possibly never?

    cheers
    Simon

  13. SPG Says:

    Simon
    You know the usual stuff that I already do.
    Will continue with that in the short to medium term.

    I will focus on VS2008, C# and XML for the medium to long term.
    (I actually want to specialise in XML – thats XML in general)

    With VSTO I will need to assess it in detail once I get hold of VS2008
    My main concern is how will it fit into Office 2003. MS focuses on 2007
    yet my clients all still use 2003. If it bridges then the next problem is
    deployment. I know 2007 are deployed using ClickOnce but I think 2003
    may not.

    I think clients will only move away from 2003 very slowly.
    Why change if it ain’t broke?

    From the streams & downloads (MS marketing, conferences, demos, etc)
    I paused the show at the create new project – office 2003 (the presenters usually just clicked this option for one second before jumping to the 2007 option) and it looks good – all the templates you need are there.

    So with VSTO its a bit of wait and see. After I work with it in VS2008 I will decide (actually thats a key point VSTO has been around since 2002/2003 I think but has always been isolated/fragmented now its actually integrated)

    If I work with VSTO then its medium to long term (ie its strategic)
    VSTO is now part of VS, I think however thats its going to be a strange transition for many people. (most won’t manage and will give up)

    VBA people moving to VSTO will actually find that the VS Object Library (not the VSTO related namespaces – all the others e.g. System.IO etc)
    will be the main hill to climb as will the dynamics of the coding language e.g. C#, polymorphism, inheritance, overloading, interfaces, etc, etc, etc.

    Most VS people moving to VSTO will struggle, but some will succeed.
    I think initially you will see a lot of VSTO work revolving around Outlook
    (funny enough) but not much around Excel. VS devs can easily make the transition to an app like Outlook.

    VS devs have a headstart in terms of the dev environment.
    VBA (re Excel) devs have a headstart (commanding) re financial knowledge. If a dev has a blend of both he will do well.

    One thing about VSTO though – if it works well I will develop commercial financial products with it, I’m bored sitting in an office thowing together projects (in whatever MS Office product) using VBA – too easy.

    Even Essbase API with VB is a bore, Cartesis Magnitude does’nt expose an API.

    Why XML? I work with so many apps its a joke. My speciality is actually data. plain old data. Excel, for example, is just a medium to me for working with data. when I work I always look through the app and focus on the underlying data. XML allows me to abstract away (my favourite term at the moment) the actual app.

  14. SPG Says:

    You may find this to be of interest.
    Short video that demonstrates:
    Calling VSTO managed code from VBA, and
    Calling VBA from VSTO managed code.
    For a change Excel is the app that is used in the demo.

    http://www.microsoft.com/uk/msdn/nuggets/nugget/281/VBA-interop-with-VSTO-managed-code-in-VS-2008.aspx

    Remember our discussion with using ‘missing’ for all optional args when writing in C#.

    Probably vb.net will be adopted by most vba people rather than C#.

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: