Catherine Heller: VSTO Demo

Play Catherine Heller: VSTO Demo

The Discussion

  • User profile image
    Brice It

    I think this video is one of the most exciting videos hosted on Channel 9.

    After watching this video, my blood started pumping a little bit faster....why? Because I can foresee my annual salary increasing about 15K a year within the next 2 years as a result of the incredible things I will be doing with the Office add-in capabilities in VS 2005.

    Your products are truly world class...

    Thank you Microsoft!

    Brice Richard

    P.S. Will the Office add-in also be provided for VS 2005 Standard edition, or just the Team Edition?

    The website for additional information on Office development tools can be found at:

    Got ya covered scoble...

  • User profile image
    I have a question.
    Is it true that both Winforms and webforms are integrated in whidbee?? if that is the case then can I code against an Excel sheet in design time to be rendered as n a web app. In other words can I use the VSTO for Web applications built using ASP.Net.

    Looking forward to your reply.

    Thanking You,
    Yours Truly,
    Sriram Ramamurthy.
  • User profile image
    The following is supposed to be on my Blog:

    VSTO 2 and VBA News

    I still use VBA for my Microsoft Word jaunts. And, as Microsoft’s Catherine Heller suggests on, the next version of VSTO will not radically revisit the extremely complex, application object model covered by VBA. It appears that the next version of VSTO is preoccupied with all the stuff shown on Channel9 and the ‘boring’ task of making sure that managed code safely and completely replaces VBA appears to be an obscure edge case that about which ‘our’ Mort cares little. I do not find it impossible that Microsoft will abandon VBA (and VBA-replication) entirely and force us to wait several years before there is a suitable replacement—an equivalent to what we now call “managed.” One possible path is that Office 14 (or maybe Office 12) will run entirely on managed code and Microsoft will simply say, “Upgrade your documents to the new file format and write your new managed code against the new managed object model.” Microsoft will be successful in file-format backwards compatibility but the code will have to be rewritten—even code written in C# or VB.NET for VSTO 1.x.

  • User profile image
    Brice It


    What on earth is wrong with managed code? What is your beef with VBA being ported as managed code into Visual Studio?

    I think the reality is that it's not outside the scope of possibility that VBA will be ported into a managed code construct within Visual Studio some time in the future.

    I personally wouldn't mind being able to use VBA's DOCMD functionality which is currently supported in MS Access as managed code within Visual Studio if it were to be ported in that fashion.

    If VBA is restructured in the future within Visual Studio, well, that's just the nature of change - .Net will reverberate change in the technology world for some time to come in unique and diversified ways.

    I welcome new and improved ways to code even if it means restructuring or eliminating VBA - by the way, I am a strong supporter and avid user of VBA in my MS Office applications.

    Brice Richard

  • User profile image
    Brice It wrote:


    What on earth is wrong with managed code? What is your beef with VBA being ported as managed code into Visual Studio?

    Nothing is "wrong" with managed code. In fact, I am translating a few thousand lines of VBA into C# tonight (just like last night). At bottom, my concern is that VSTO 2.0 may require me to translate my code again. Take this for example:

    /// <summary>

    /// Returns a data-only Word XML string.

    /// from the specified Word XML Node.

    /// </summary>

    /// <param name="XmlNode">Word XML Node</param>

    /// <remarks>

    /// Unfortunately the C# version of VSTO 1.x does not support

    /// the <c>Word.XMLNode.XML()</c> method and its "raw getter" is exposed

    /// for our temporary use.

    /// </remaarks>

    internal static string GetXml(Word.XMLNode XmlNode)


    return XmlNode.get_XML(true);


    What's "wrong" with get_XML()? In VBA, it's XmlNode.XML(true). What I need to hear is that Microsoft is eager to hide the "raw getter" get_XML() and wrap it up in XML(). What may really happen, is that this syntax will be replaced with an entirely different approach that is not compatible with VBA (and VSTO 1.x's incomplete translation of VBA functionality).

  • User profile image
    Thank you very much for this Video Smiley

    The explanations of Catherine are very good and her skill is incredible Smiley

    This woman rocks !
  • User profile image


    I wish the video recording (Product / Code Demo) was recorded bit appropriately; its too difficult to catch-up with the demo while the camera man keeps moving the camera here-n-there and keeps zooming here-n-there.

    I guess it would be good to have a static view of the demo

    My 2 cents



  • User profile image
    Orion Adrian
    My question is the same question as I had when I first saw this technology. I've done a lot of work with Excel User Defined Functions and while they're pretty easy in to make in VBA, there are some things I'd like to get out of the managed code world. Is there any plans on allowing Excel User Defined Functions to be written in .Net?
  • User profile image

    Catherine says that before VSTO the only option for document level customisations was to use VBA. However, with VSTO 2005 SE, this is still the case (except for Infopath document level customisations) as it only allows you to create application level add-ins. Hopefully, this is just an intermediate stage until the next version of VSTO.

Add Your 2 Cents