In order to provide a more integrated experience for folks building custom solutions on the Office platform, we’ve merged the content from the VSTO Developer Center into the Office Developer Center. You’ll still find great learning content there including:

Getting Started with Office Development with Visual Studio (VSTO)

 Excel Solutions

Write code to work with data and customize the user interface.

 Outlook Solutions

Work with objects and data and customize the Outlook user interface.

 Word Solutions

Manipulate documents, work with data, and customize the Word user interface.

 Deploying Office Solutions

Learn to deploy Office customizations built with Visual Studio.

Happy Learning!
- The VSTO Team

If you missed it, last week the InfoPath team posted about how to migrate your InfoPath projects from Visual Studio Tools for Office 2005 or Visual Studio Tools for Office 2008 (VSTO) into InfoPath 2010 using Visual Studio Tools for Applications (VSTA).

Check it out here: Working with VSTO 2008 Projects in InfoPath 2010

Signing your Office solutions with a certificate is a mandatory step, but there are several optional steps that can change the way the certificate is presented to the end user or customer.

This example uses a Visual Studio generated test certificate, but the dialog box is similar to what you would see if you are using a purchased code-signing certificate. These steps are listed in the How to: Add a Trusted Publisher to a Client Computer for ClickOnce Applications topic in the MSDN Library and assumes that the ClickOnce Trust Prompt and inclusion list are enabled as outlined in How to: Configure Inclusion List Security

Phase 1. If the certificate used to sign the Office solution is not added to the Root or the TrustedPublisher stores, the Publisher is shown as Unknown Publisher and there is a yellow shield presented in the Microsoft Office Customization Installer dialog box.

Phase 2. If the certificate used to sign the Office solution is in the Root store, but not the Trusted Publisher list, the Publisher is shown as Redmond\marylee and there is a green shield.

The step used to add the certificate to the Root store is the following: certmgr.exe -add good.cer -c -s -r localMachine Root

Phase 3. If the certificate used to sign the add-in is in the Root list and the Trusted Publisher list, you only see that the add-in was installed successfully.

The step used to add the certificate to the TrustedPublisher store is the following: certmgr.exe -add good.cer -c -s -r localMachine TrustedPublisher

If you have questions, visit the VSTO forum to search for answers or post new questions.

Mary Lee, Programming Writer.

With the SP1 work winding down, I thought that I’d take a moment and discuss three new performance improvements that are going into VSTO for SP1. We have listened to your feedback and understand that startup time is a major issue, and so we have focused on attempts to make the VSTO runtime load faster.

In this article, I will be delving into these features and how you can take advantage of them. The most important feature is Fast Path loading, which is a loading path for the runtime which is as fast and as lean as possible. In addition, we updated the form region and ribbon discovery process so reflection is not required in most cases. Plus, I will also share a few of the numbers we gathered during this effort so that you can get a before and after picture.

VSTO Fast Path

The Fast Path is a new way to load and launch VSTO addins that is much faster than the current launch path. However, it achieves this speed by bypassing a few of the steps that would normally happen during addin launch. The following conditions must be met in order to use the fast path:

1. The addin (or document) manifest must be installed under %ProgramFiles% or %ProgramW6432%.
2. The addin must be registered as |vstolocal in the registry.

When the fast path is in use, the following steps will be skipped:

1. Schema validation on the manifests
2. Any automatic update checking
3. Security checks – the digital signatures of the manifests will not be validated.

Notice that the requirement that the add-in is deployed into the secure location on the user machine allows us to relax the security verifications done at runtime without compromising the security of the machine. Relaxing these expensive checks is what contributed the most to the improvements in startup time.

In order to take advantage of Fast Path loading, an addin has to be deployed via an MSI. As a consequence, these addins also will not be able to automatically check for updates.

Ribbon Aware Manifests

As mentioned in a previous blog post, VSTO reflects over the addin assembly in order to find Ribbon extensions. On particularly large assemblies, this can be quite time consuming. While there have been manual workarounds for this behavior in the past, we are now including Ribbon extension types directly into the VSTO manifest. If there are no Ribbon extensions, then an empty list is placed in the manifest, which will tell the VSTO runtime that reflection is not necessary.

In order to take advantage of this improvement, the addin must be built (or rebuilt) with Visual Studio 10.0 SP1, and the addin must be loaded with the SP1 version of the VSTO Runtime. The addin must also be targeting .Net 4.0. If you attempt to load an SP1 addin with a RTM runtime, or if you load an RTM addin with the SP1 runtime, all of the ribbon objects will still be discovered and loaded; the runtime will just have to use reflection to find them.

Of course, if your code already overrides CreateRibbonObjects or CreateRibbonExtensibilityObject as mentioned in the above blog entry, then this optimization does not apply to you. The reason why this was implemented is because many people are not aware of this optimization, and we want to ensure that we are as performant as possible by default with as little manual optimization as possible.

To better visualize the new ribbon xml, here are two examples of its intended use:

<vstov4:appAddIn application="Excel" loadBehavior="3" keyName="ExcelAddIn14">
  <vstov4:friendlyName>ExcelAddIn14</vstov4:friendlyName>
  <vstov4:description>ExcelAddIn14</vstov4:description>
  <vstov4.1:ribbonTypes xmlns:vstov4.1="urn:schemas-microsoft-com:vsto.v4.1">
    <vstov4.1:ribbonType name="ExcelAddIn14.Ribbon1, ExcelAddIn14, 
        Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
  </vstov4.1:ribbonTypes>
</vstov4:appAddIn>

That addin had one ribbon type, and the class is called ExcelAddIn14.Ribbon1, and it is part of the ExcelAddIn14.dll assembly.

Here is one with no ribbons:

<vstov4:appAddIn application="Excel" loadBehavior="3" keyName="ExcelAddIn15">
  <vstov4:friendlyName>ExcelAddIn15</vstov4:friendlyName>
  <vstov4:description>ExcelAddIn15</vstov4:description>
  <vstov4.1:ribbonTypes xmlns:vstov4.1="urn:schemas-microsoft-com:vsto.v4.1" />
</vstov4:appAddIn>

The empty ribbonTypes list serves to tell the SP1 runtime that doing the reflection is unnecessary. This will save a lot of time during VSTO startup.

VSTO Form Region discovery

When loading an Outlook addin that has Form Regions, the VSTO Runtime uses reflection to discover Form Region factories and match them up with Form Regions registered with the addin. This had the potential to inflict a serious performance hit, especially if the addin assembly contained a lot of different types.

To eliminate this performance hit, the name of the factory is now being included in the addin manifest. Now when Outlook requests the factory from the addin, the addin knows immediately which class to instantiate and doesn’t need to reflect over every type in the assembly to find the appropriate class. If you look in the new SP1 manifest, you can see the new information:

<vstov4:formRegion 
    name="Outlook_OFR_MSI.EmptyFormRegion" 
    vstov4.1:class="Outlook_OFR_MSI.EmptyFormRegion+EmptyFormRegionFactory" 
    xmlns:vstov4.1="urn:schemas-microsoft-com:vsto.v4.1">

Like the Ribbon aware manifest above, the SP1 runtime is capable of loading an addin with Form Regions that was built with the RTM version of VS, and the RTM runtime can load an SP1 addin. You just won’t be able to take advantage of this improvement.

Numbers

Below are some of the numbers that we tracked on startup time during this effort. These numbers were collected on a machine in a ‘cold’ state (everything in memory flushed out to disk, superfetch disabled) in order to give us the most consistent results during our work. In addition, there are no other applications running at the time that Outlook was launched, and all addins except for the one that we were testing was disabled.

There four startup times of interest are as follows:

1. Outlook application baseline – an empty mail account, no addins loaded
2. Outlook simple addin – a simple .Net 4.0 addin. In SP1, it would take advantage of the fastpath as well as the ribbon improvements (since the VSTO runtime was no longer looking for Ribbons)
3. Outlook Ribbon addin – this is similar to the above one, only now we see the time it takes to instantiate a simple Ribbon extension.
4. Outlook WPF Form Region – this is the simple addin plus the time to load (but not show) a Form Region with a WPF control on it. This takes advantage of all of the improvements listed in this article.

As you can see, there are many performance improvements to the VSTO Runtime coming in Visual Studio 2010 SP1. Not only that, but many tweaks that used to require extra work (such as working around Ribbon reflection) are now available out of the box with no interaction on the user’s part. This will help you deliver VSTO addins that are faster to your end-users.

UPDATE: Visual Studio SP1 Beta is now available!

Paul O’Rear, a Program Manager on the Library Experience team, describes the changes to the Microsoft Help Viewer planned for Visual Studio 2010 SP1. He demonstrates the new functionality of the viewer in an early build of Help Viewer 1.1.

See Microsoft Help Viewer – Updates Planned for Visual Studio 2010 SP1

You can learn more in The Story of Help in Visual Studio 2010 

--Kathleen

You have probably been reading and hearing about Microsoft Office 2010 for some months. Now, you may be wondering how much work is necessary to install your existing Office 2007/VSTO 3.0 solutions on customer computers that have Office 2010. Perhaps you’re thinking about migrating the Windows Installer Setup projects or ClickOnce deploymen projects? The answer is that you don’t need to change anything. If you have Office 2007 add-ins that were created for the VSTO 3.0 runtime, the registry keys for Office 2010 add-ins created for the VSTO 2010 runtime are exactly the same. For Office 2007 document-level projects, the custom document properties are also the same in Office 2010. The same deployment project used to install Office 2007 solutions should work on Office 2010 as well.

In fact, deployment becomes even easier for two reasons: fewer prerequisites to include and fewer custom actions to run.

1. Less need to deploy the VSTO runtime. The VSTO 2010 runtime with the .NET Framework 3.5 extensions is already included in Microsoft Office 2010. For more information, see http://blogs.msdn.com/b/vsto/archive/2010/05/13/when-do-i-need-to-deploy-the-vsto-runtime.aspx.
2. Less need for the inclusion list. VSTO add-ins installed to the Program Files directory are considered trusted without creating an inclusion list entry for each solution and each user. For more information, see http://blogs.msdn.com/b/vsto/archive/2010/03/10/changes-in-the-security-model-for-office-solutions.aspx.

MSDN Library resources include the following topics:

• Visual Studio Tools for Office Runtime Installation Scenarios
• Trusting Office Solutions by Using Inclusion Lists

If you have any questions, search for answers or post questions in the Visual Studio Tools for Office forum at http://social.msdn.microsoft.com/Forums/en-US/vsto/threads.

Mary Lee, Programming Writer.

Today we released the Microsoft Office 2010 Primary Interop Assemblies (PIA) Bootstrapper Installer which adds the Microsoft Office 2010 Primary Interop Assemblies to the Prerequisites Dialog Box in Visual Studio 2010 or Visual Studio 2008. Then when you deploy with ClickOnce or Windows Installer, you can select this option to deploy the Microsoft Office 2010 PIAs to end-user computers.

Download it here: Microsoft Office 2010 Primary Interop Assemblies (PIA) Bootstrapper Installer

Make sure to read the instructions on the download page in order to properly set up the bootstrapper to appear in Visual Studio. Now when you create Office 2010 solutions with Visual Studio 2010 you can select to deploy this prerequisite component with your solution to your end users.

For more information on developing Office solutions with Visual Studio please visit the Office Development with Visual Studio Developer Center.

Enjoy,
-Beth Massi, Visual Studio Community

In Visual Studio 2010, you can use the ClickOnce and Windows Installer deployment technologies to deploy Office solutions that target both Microsoft Office 2007 and Microsoft Office 2010. The main advantage of using Windows Installer to deploy your Office solutions is to install application-level add-ins to AllUsers, rather than the current user only.

There are detailed steps for creating a Windows Installer (.msi) file for Office 2007 and Office 2010 solutions at http://msdn.microsoft.com/en-us/vsto/ff937654.aspx and code samples at http://code.msdn.microsoft.com/VSTO2010MSI.

For information about the registry keys for deploying to AllUsers, see http://msdn.microsoft.com/en-us/library/bb386106.aspx.

For developers using Windows Installer XML, there is some useful information at http://stackoverflow.com/questions/532447/how-do-you-use-wix-to-deploy-vsto-3-0-addins. The steps are similar for Office solutions in Visual Studio 2010.

If you have any questions about the steps, search for answers or post questions in the Visual Studio Tools for Office forum at http://social.msdn.microsoft.com/Forums/en-US/vsto/threads.

Mary Lee, Programming Writer.

Saurabh Bhatia, Program Manager.

In this interview, I sit down with Stephen Peters, a developer on the Office client tools team in Visual Studio. Steve shows us a couple of tricks for how you can squeeze the best performance out of Office solutions built with Visual Studio (VSTO). He also shows how to finely control the way your custom ribbons load, as well as how to eliminate references to the Utilities assembly. Check it out:

Channel 9 Interview: Office Add-in (VSTO) Performance Tips & Tricks

For more information, see his blog post:
VSTO Performance: Ribbon Reflection

Enjoy,
-Beth Massi, Visual Studio Community

A customer on the VSTO forums recently noticed that the steps we blogged about for sharing a single Ribbon customization between multiple projects in Visual Studio 2008 no longer works in Visual Studio 2010. When following the instructions in the blog post, you get an error when you try to open the Ribbon code file in the class library project. This is because of some changes to the way the Ribbon designer was implemented in Visual Studio 2010. The upshot is that you can no longer open the Ribbon designer outside of Office projects. In addition, because Office projects that target the .NET Framework 4 have a different programming model in Visual Studio 2010, the instructions in the old blog post will also result in other errors in projects that target the .NET Framework 4.

This blog post tells you how to share a single Ribbon customization (created by using the Ribbon designer) between multiple Office projects in Visual Studio 2010. Disclaimer – what I am about to show you in this blog post is not supported, and has not been officially tested by the product team in any way.

Targeting the .NET Framework 3.5

If your Office projects target the .NET Framework 3.5, then the instructions in the old blog post still apply, with just one change. Rather than design your Ribbon customization in the class library project, now you must design it in an Office project, because of the change to the implementation of the Ribbon designer noted above. Here are the modified instructions.

1. In Visual Studio, open (or create) an Office project that targets the .NET Framework 3.5, and that targets an Office application that supports the Ribbon.
2. Add a Ribbon (Visual Designer) item to the project.
3. Design your Ribbon customization. Be sure to set the Modifiers property to Public for any controls/tabs/groups that you want to be able to access in other Office projects. Also be sure to set the RibbonType property of the Ribbon to all Ribbon types you want to support in other Office projects that consume the shared Ribbon. For example, if you want to use the Ribbon customization in Excel and Word projects, set RibbonType to Microsoft.Excel.Workbook and Microsoft.Word.Document.
4. Save your changes.
5. Create a class library project that targets the .NET Framework 3.5. Add the following reference:
   • Microsoft.Office.Tools.Common.v9.0
6. Add the existing Ribbon code file to the class library project. The code-behind file (for example, Ribbon1.Designer.cs) will be copied over automatically.
7. Optionally, open the Ribbon file and the code-behind file in the editor and change the namespaces for the Ribbon class in the main Ribbon file and code-behind file (for example, to SharedRibbonLibrary or some other namespace that identifies your component). Be sure to open the files in the editor by right-clicking them and choosing View Code. Do not double-click the files; this will attempt to open the Ribbon designer, and will result in a designer error.
8. Build the class library project.
9. In a new/different Office project that targets the .NET Framework 3.5, add a reference to the class library project.
10. In the ThisAddIn, ThisDocument, or ThisWorkbook class in the Office project, override CreateRibbonObjects as follows (the following code assumes you changed the namespace of the shared Ribbon to SharedRibbonLibrary).

    protected override Microsoft.Office.Core.IRibbonExtensibility CreateRibbonExtensibilityObject()
    {
        return new Microsoft.Office.Tools.Ribbon.RibbonManager(
            new Microsoft.Office.Tools.Ribbon.OfficeRibbon[] { 
                new SharedRibbonLibrary.Ribbon1() });
    }
    

    
    
11. Add the following class to the project. This code lets you access the shared Ribbon customization by using Globals.Ribbons in your code.

    partial class ThisRibbonCollection : Microsoft.Office.Tools.Ribbon.RibbonReadOnlyCollection
    {
        internal SharedRibbonLibrary.Ribbon1 Ribbon1
        {
            get { return this.GetRibbon<SharedRibbonLibrary.Ribbon1>(); }
        }
    }
    

    
    
12. Now you can use Globals.Ribbons.Ribbon1 to access public items exposed by the shared Ribbon. For example:

    private void ThisAddIn_Startup(object sender, System.EventArgs e)
    {
        Globals.Ribbons.Ribbon1.button1.Click += new EventHandler<Microsoft.Office.Tools.Ribbon.RibbonControlEventArgs>(button1_Click);
    }
    
    void button1_Click(object sender, Microsoft.Office.Tools.Ribbon.RibbonControlEventArgs e)
    {
        System.Windows.Forms.MessageBox.Show("it works!");
    }
    
    

    
    

Targeting the .NET Framework 4

If your Office projects target the .NET Framework 4, you’ll need to make a number of other changes to the Ribbon code. Here are the full instructions.

1. In Visual Studio, open (or create) an Office project that targets the .NET Framework 4, and that targets an Office application that supports the Ribbon.
2. Add a Ribbon (Visual Designer) item to the project.
3. Design your Ribbon customization. Be sure to set the Modifiers property to Public for any controls/tabs/groups that you want to be able to access in other Office projects. Also be sure to set the RibbonType property of the Ribbon to all Ribbon types you want to support in other Office projects that consume the shared Ribbon. For example, if you want to use the Ribbon customization in Excel and Word projects, set RibbonType to Microsoft.Excel.Workbook and Microsoft.Word.Document.
4. Save your changes.
5. Create a class library project that targets the .NET Framework 4. Add the following references:
   • Microsoft.Office.Tools
   • Microsoft.Office.Tools.Common
   • Microsoft.Office.Tools.Common.v4.0.Utilities
6. Add the existing Ribbon code file to the class library project. The code-behind file (for example, Ribbon1.Designer.cs) will be copied over automatically.
7. Open the Ribbon file and code-behind file in the code editor by right-clicking them and choosing View Code. Do not double-click the files; this will attempt to open the Ribbon designer, and will result in a designer error.
8. In the Ribbon code-behind file, change the constructor to the following.

   public Ribbon1(Microsoft.Office.Tools.Ribbon.RibbonFactory factory)
   
       : base(factory)
   
   {
   
       InitializeComponent();
   
   }
   

   
   
9. In Ribbon code-behind file, remove the ThisRibbonCollection class definition at the bottom of the file. 
10. Optionally, change the namespaces for the Ribbon class in the main Ribbon file and code-behind file (for example, to SharedRibbonLibrary or some other namespace that identifies your component).
11. Build the class library project.
12. In a new/different Office project that targets the .NET Framework 4, add a reference to the class library project.
13. In the ThisAddIn, ThisDocument, or ThisWorkbook class in the Office project, override CreateRibbonObjects as follows (the following code assumes you changed the namespace of the shared Ribbon to SharedRibbonLibrary).

    protected override Microsoft.Office.Tools.Ribbon.IRibbonExtension[] CreateRibbonObjects()
    
    {
    
        return new Microsoft.Office.Tools.Ribbon.IRibbonExtension[] { new        
    
            SharedRibbonLibrary.Ribbon1(Globals.Factory.GetRibbonFactory()) };
    
    }
    

    
    
14. Add the following class to the project. This code lets you access the shared Ribbon customization by using Globals.Ribbons in your code.

    partial class ThisRibbonCollection : Microsoft.Office.Tools.Ribbon.RibbonReadOnlyCollection
    
    {
    
        internal SharedRibbonLibrary.Ribbon1 Ribbon1
    
        {
    
            get { return this.GetRibbon<SharedRibbonLibrary.Ribbon1>(); }
    
        }
    
    }
    
    

    
    
15. Now you can use Globals.Ribbons.Ribbon1 to access public items exposed by the shared Ribbon. For example:

    private void ThisAddIn_Startup(object sender, System.EventArgs e)
    {
        Globals.Ribbons.Ribbon1.button1.Click += new Microsoft.Office.Tools.Ribbon.RibbonControlEventHandler(button1_Click);
    }
    
    void button1_Click(object sender, Microsoft.Office.Tools.Ribbon.RibbonControlEventArgs e)
    {
        System.Windows.Forms.MessageBox.Show("it works!");
    }