During development of the VSTO 2010 Runtime we added a feature, dubbed Install on Demand, to support VSTO customizations that target both .NET Framework 3.5 and .NET Framework 4 without enforcing installation of both frameworks prior to installation of VSTO 2010. To facilitate this we needed to break the runtime into 3 components as shown in this diagram.

VSTO Loader can be viewed as the native component of the VSTO 2010 Runtime that communicates with Office. It has no managed dependency and is the only component of the VSTO 2010 Runtime that is guaranteed to be “turned on” no matter how the runtime is installed (the different installation scenarios are discussed below). The extensions (Office 3.5 Runtime Extensions and Office 4.0 Runtime Extensions), shown above VSTO Loader, are the components necessary to execute customizations that target the corresponding version of the .Net Framework. The red arrows indicate which .Net Framework version the extensions depend on.

To better understand how the new Install on Demand functionality will affect you and your end users I will explain the impact from the 3 distinct scenarios with which the VSTO 2010 Runtime can be installed.

• Visual Studio 2010
• Office 2010
• VSTO 2010 Runtime redistributable

Because of these different scenarios we could not assume (or enforce a prerequisite) that any particular version of the .NET Framework was installed on an end users machine at the time they install the VSTO 2010 Runtime. To make this clear, imagine you are deploying a customization that targets .Net Framework 3.5 to a customer who has not yet moved to .Net Framework 4. If we were to unconditionally install all 3 components in the diagram above we would be forced to prereq the .Net Framework 4 which would mean your customer would have to install .Net Framework 4 even though your customization would not require it. Similarly, if you were deploying a customization that targets .Net Framework 4 to a customer that has .Net Framework 4 and no .Net Framework 3.5 we would have to prereq .Net Framework 3.5. What we did was to allow the extensions to only be “turned on” once the version of the .NET Framework that they depend on was present. As a result of the Install on Demand design we have made it more flexible for developers and end users to install the VSTO 2010 Runtime "once" and forget about it. No manual configuration of VSTO is required after installing a version of the .Net Framework that “lights up” either of the extensions.

Visual Studio 2010

VSTO 2010 Runtime, as it has been in past Visual Studio releases, is chained in with the Visual Studio 2010 installation. Developers who install Visual Studio 2010 on a machine without .NET Framework 3.5 will have the Office 4.0 Runtime Extensions “turned on” and the Office 3.5 Runtime Extensions “turned off” (but ready to be “turned on” when applicable) as is shown here.

If the developer decides to start creating .Net Framework 3.5 customizations they are going to need to install the .NET Framework 3.5. After the .Net Framework 3.5 installation when the developer launches Visual Studio 2010 they will be able to target .NET Framework 3.5. However, the VSTO 2010 Runtime still does not have the Office 3.5 Runtime Extensions “turned on”. No worries, this will be taken care of for the developer the first time they create a VSTO project that targets .Net Framework 3.5. During this initial project creation you will notice an MSI configuration dialog appear.

When the project is successfully created the VSTO 2010 Runtime will have installed the Office 3.5 Runtime Extensions which will transition the runtime into the following state allowing the project to be F5’d.

If .NET Framework 3.5 was on the box prior to the Visual Studio 2010 installation then the runtime will be installed in its entirety (both Office 3.5 and Office 4.0 Runtime Extensions “turned on”) and no Install on Demand will take place from that point on. 

Office 2010

If you weren’t already aware, VSTO 2010 will be included in the Office 2010 installation. This is great news for end users who will not have to install the VSTO 2010 Runtime redistributable to execute customizations that target .Net Framework 3.5. Note that in the Beta and RTM releases of Office 2010 you will NOT get Office 4.0 Runtime Extensions (or the capability for them to be “turned on”). If you are deploying customizations that target .Net Framework 4 and they will run on Office 2010 you will need your users to install the VSTO 2010 Runtime redistributable (and of course before their customization will run they will have to install .Net Framework 4).

End users who install Office 2010 will receive the VSTO runtime and the Office 3.5 Runtime Extensions “turn on” capability. That is, if .NET Framework 3.5 is on the machine then these extensions will be installed and “turned on” otherwise they will be ready to "turn on”.

VSTO 2010 Runtime redistributable

End users who install the redistributable, either through the bootstrapper (setup.exe) or the download center, will receive both extensions and be able to run customizations that target both .Net Framework 3.5 and 4. No matter how the machine is configured, at the time the redistributable is installed, all deployed solutions will be able to run as long as the appropriate target .Net Framework version is present. Note that this is not limited to ClickOnce deployment, custom MSI deployment will also work this way. For customizations deployed via ClickOnce the “turning on” of extensions will occur during the installation process and for MSI deployment on first load of the customization. In both these cases users will see the MSI configuration dialog (shown in the image above) briefly.

In conclusion, Install on Demand coupled with the VSTO 2010 Runtime shipping with Office 2010 simplifies many deployment scenarios. End users of Office 2010 customizations that target .Net Framework 3.5 will never need to manually install the VSTO 2010 Runtime nor know of its existence. Those still using Office2007 or Office 2010 with .Net Framework 4 will have the flexibility to install the VSTO 2010 Runtime without worrying if they have the correct .Net Framework down before doing so.

Early last year we built a business application for order management for Northwind Traders on the Office and SharePoint platform using Visual Studio 2008 and Office & SharePoint 2007. Recently I started releasing articles on my blog that show how to upgrade the VS2008 version to VS2010:

• Migrating an Outlook Client to .NET Framework 4 in Visual Studio 2010
• Build WPF Data Controls for Outlook Addins Easily with VS2010
• Migrating a 2007 Workflow to Visual Studio & SharePoint 2010

Today I updated the sample with some more goodies including some SharePoint 2010 web parts that I’ll write about soon. But I wanted to let you know sooner rather than later that you can play with all of the code today.

Here ya go: http://code.msdn.microsoft.com/OBANorthwind

This sample was built using Visual Studio 2010 Beta 2, Office 2010 Beta & SharePoint 2010 Beta and it demonstrates:

1. A way to easily expose line-of-business (LOB) data using WCF Data Services (formerly known as ADO.NET Data Services)
2. An Outlook 2010 Add-in that displays LOB data in a WPF control that I built in 5 minutes using the new drag-drop data binding and designer features
3. How to store and retrieve structured data from Word 2010 documents
4. An Excel 2010 document customization that edits LOB data through the data service and provides data visualization
5. A SharePoint 2010 Document Library Workflow that adds Order info to the database by reading word documents and updates and reports order statuses based on changes in the database using the data service
6. A SharePoint 2010 Visual Web Part that reports low inventory in the database using the data service and allows users to add tasks
7. A SharePoint 2010 Silverlight Web Part that demonstrates how to deploy Silverlight web parts to SharePoint 2010 and use the SharePoint Silverlight client library to add tasks

Enjoy,
-Beth Massi, Visual Studio Community

There have been a couple of blog posts about delay loading VSTO addins, and with Dev10 being released soon, it’s a good time to expand on the subject a little bit.

This has been covered before, and I’ll avoid spending too much time here on topics that have already been covered.  For an overview of delay loading, please read these posts.

http://blogs.msdn.com/andreww/archive/2008/07/14/demand-loading-vsto-add-ins.aspx

http://blogs.msdn.com/andreww/archive/2008/04/19/delay-loading-the-clr-in-office-add-ins.aspx

There are many reasons why you would want to delay load your addin, the most important of which is for performance – loading the CLR can easily double the amount of time that it takes to load an Office application. If your addin is only used occasionally, your users will appreciate the faster load times.

One important improvement that has gone into Dev10 is that you no longer need to manually change the LoadBehavior in the registry for your addin to make it DelayLoad. If you go into project properties of your addin, click on the “Publish” tab, and go into “Options…”, you can adjust the Add-in Load Behavior under “Office Settings”.

For more information about publishing, please see Publishing VSTO Solutions.

Now, once you have done this, your addin will not be loaded until Office decides that it needs to load the addin. This can happen a number of ways, but the most common is that a user action (like clicking on a ribbon button) calls into the addin, and causes the addin to be loaded.

One important note is that any custom “get” handler (getEnabled, getVisible, getLabel) will not trigger the loading of your addin. The first time that your addin is loaded, Office will call the handler and cache the response given, and use that response as the default.  It will then call the handler again to use in the current session.  This is important because if the control is disabled initially, and then later enabled via a call to RibbonUI.Invalidate or RibbonUI.InvalidateControl, it will only invalidate this second value and not the first value. 

Consider the following example where a database connection is necessary for the addin to function:

XML:

<group id="MyGroup"
       label="Database controls"  >
    <button id="Button1" label="Get Data" onAction="GetDataClick" getEnabled="GetEnabled" />
</group>

Callbacks in Ribbon Class:

#region Ribbon Callbacks

Boolean dbEnabled = false; 
public void Ribbon_Load(Office.IRibbonUI ribbonUI)
{
    this.ribbon = ribbonUI;

    //[aDeveloper] moving the database connection to another thread
    Thread databaseConnectionThread = 
        new Thread(delegate()
        { 
            Thread.Sleep(500); // todo:  Actually connect
            dbEnabled = true;
            ribbon.Invalidate();
        });
    databaseConnectionThread.Start();
}

public Boolean GetEnabled(Office.IRibbonControl rc)
{
    return dbEnabled;
}

public void GetDataClick(Office.IRibbonControl rc)
{
    //pull data from the database and populate the spreadsheet with it.
}
#endregion

This can cause a chicken and egg type situation if by default none of its ribbon controls are available (Ie, they’re not enabled or visible). The next time Office is started, it will use the cached “false” response resulting in none of the controls being enabled, and the user will have no easy way to load the addin and cause the “get” handlers to be called.

The best way around this issue would be to have a control that is always enabled that calls into the addin and thus would load the addin. You can then call ribbonUI.Invalidate in the custom UI’s onLoad handler to force the Office application to call each “get” handler.

XML:

<group id="MyGroup"
       label="Database controls">
    <button id="Button0" label="Connect Database" onAction="ConnectDatabase" enabled="true" />
    <button id="Button1" label="Get Data" onAction="GetDataClick" getEnabled="GetEnabled" />
</group>

Callbacks in Ribbon Class:

#region Ribbon Callbacks

Boolean dbEnabled = false; 
public void Ribbon_Load(Office.IRibbonUI ribbonUI)
{
    this.ribbon = ribbonUI;
}

public Boolean GetEnabled(Office.IRibbonControl rc)
{
    return dbEnabled;
}

public void GetDataClick(Office.IRibbonControl rc)
{
    //pull data from the database and populate the spreadsheet with it.
}

public void ConnectDatabase(Office.IRibbonControl rc)
{
    //[aDeveloper] we don't do this automatically since we don't want to connect to the database
    //             unless the user wants to - there's a chance for a hang if the database isn't
    //             available.
    Thread.Sleep(500); // todo:  Actually connect
    dbEnabled = true;
    ribbon.Invalidate();
}
#endregion

Another trick is to have the handler return “true” the first time that it’s called, so that Office caches the “true” response as the default, and the control is enabled.  If you do this, you’ll want to make sure that your click handlers can handle the case where the button should be disabled.

(n.b.:  This example is a little bit contrived, but will illustrate what you need to do if your application would be best served by this behavior.) 

In this case, the “Get Data” button will be enabled by default.  The first click will generate the message box since by the time that GetDataClick is called, the addin hasn’t had time to ‘connect’, and the button will remain disabled until the connection is done.

XML:

<group id="MyGroup"
       label="Database controls">
    <button id="Button1" label="Get Data" onAction="GetDataClick" getEnabled="GetEnabled" />
</group>

Callbacks in Ribbon Class:

#region Ribbon Callbacks
Boolean dbEnabled = false;
Boolean firstCall = true;
public void Ribbon_Load(Office.IRibbonUI ribbonUI)
{
    this.ribbon = ribbonUI;
    //[aDeveloper] moving the database connection to another thread so that we don't hang office
    Thread databaseConnectionThread = 
        new Thread(delegate()
        { 
            Thread.Sleep(5000); // todo:  Actually connect
            dbEnabled = true;
            ribbon.Invalidate();
        });
    databaseConnectionThread.Start();
}

public Boolean GetEnabled(Office.IRibbonControl rc)
{
    if (true == firstCall)
    {
        firstCall = false;
        return true;
    }
    return dbEnabled;
}

public void GetDataClick(Office.IRibbonControl rc)
{
    if (false == dbEnabled)
    {
        System.Windows.Forms.MessageBox.Show("Could not connect to database");
                
        //Disable this button until we get the connection up.
        firstCall = false;
        ribbon.Invalidate();
        return;
    }
    //Get the data and populate the spreadsheet
}
#endregion