Creating an Add-in for Office 2007 and Office 2010 that "Lights Up" on Office 2010 (McLean Schofield)

Rate This
  • Comments 9

Managed Office add-ins traditionally have been able to run in the targeted application (the version of the application whose PIAs the add-in references) and in later versions of the application. Therefore, if you need to create a single VSTO add-in that can be run in multiple versions of an application, the typical guidance is to develop the add-in by using a project template for the oldest version of Office that you want to support. For example, if your add-in needs to work with Office 2003 and Office 2007, you should create an Excel 2003 add-in (by using VSTO 2005 SE with Visual Studio 2005, or by using Visual Studio 2008).

However, this strategy has several inconveniences:

  • If you want to test/debug/run the add-in on your development computer, you must have the earliest version of Office you are targeting installed. Since side-by-side installations of Office are not supported on the development computer for VSTO development,if you're targeting an older version of Office this means that you cannot use the current version of Office on your development computer (for example, if you need to do some non-development work in Office).
  • Your add-in is limited to using only those features that are available in the earliest version of Office that you are targeting. You can work around this by creating a different add-in for each version of the application you are targeting and refactoring any common business logic into a shared assembly, or by using more advanced (and unsupported) methods, but this adds to the complexity of the development and deployment process.

With Visual Studio 2010, this scenario gets better. If you target the .NET Framework 4, you can now create a single add-in that targets both Office 2007 and Office 2010, and uses features that are available only to Office 2010 (this is the “lights up” part of the title of this blog). This is possible by virtue of the new embedded interop types feature in Visual Studio 2010 (also sometimes referred to as no-PIA or by the related /link compiler option). When you compile an add-in project that targets the .NET Framework 4, by default* the type information for all the PIA types referenced in the add-in code is embedded in the add-in assembly. At run time, this type information is used to resolve calls to the underlying COM type, rather than relying on type information in the PIAs.

The most commonly touted benefit of this feature is that because the add-in is no longer tightly coupled with the PIAs at compile time, the PIAs are no longer necessary on end user computers. However, this also means that you can now create an add-in that targets Office 2010, and the add-in will also run in Office 2007. The one caveat is this: when the add-in is loaded in Office 2007, it can use only those types/members that are available in Office 2007. You can achieve this by using the Application.Version property, and writing conditional code that uses an Office 2010-specific type/member only if the add-in is loaded in Office 2010. If the add-in is loaded in Office 2007, your code can do something else.

The following example demonstrates this technique in a Word 2010 add-in project that targets the .NET Framework 4. If the add-in is loaded in Word 2010, the code adds a check box content control (this is a new type of content control that was introduced in Word 2010) to the beginning of the active document. If the add-in is loaded in Word 2007, then it instead adds a Windows Forms check box, since this type of control can be added to a document in either version of Word.

if (Globals.ThisAddIn.Application.ActiveDocument != null)
Word.Document activeDoc = Globals.ThisAddIn.Application.ActiveDocument;

string majorVersionString = Globals.ThisAddIn.Application.Version.Split(new char[] { '.' })[0];
int majorVersion = Convert.ToInt32(majorVersionString);

if (majorVersion >= 14)
// Add a check box content control.
Word.ContentControl checkBoxContentControl1 = activeDoc.ContentControls.Add(
Word.WdContentControlType.wdContentControlCheckBox, activeDoc.Paragraphs[1].Range);
checkBoxContentControl1.Checked = true;
else if (majorVersion >= 12)
// Add a Windows Forms check box. This code requires a reference to Microsoft.Office.Tools.v4.0.Utilities
Microsoft.Office.Tools.Word.Document vstoDoc = Globals.Factory.GetVstoObject(activeDoc);
Microsoft.Office.Tools.Word.Controls.CheckBox checkBox1 = vstoDoc.Controls.AddCheckBox(
vstoDoc.Paragraphs[1].Range, 15, 15, "checkBox1");
checkBox1.Checked = true;

Here’s another example that demonstrates this technique in an Outlook 2010 add-in that targets the .NET Framework 4. When the PageChange event of an Inspector is raised, this code uses the new ActivateTab method in Office 2010 to activate a custom Ribbon tab if the user navigated to a custom form region page. This code assumes the add-in project has a Ribbon (Visual Designer) item named Ribbon1 that defines a custom tab named MyCustomTab, and a Form Region item (of type Separate) named MyCustomFormRegion.
void Inspector_PageChange(ref string ActivePageName)
string majorVersionString = Globals.ThisAddIn.Application.Version.Split(new char[]{'.'})[0];
int majorVersion = Convert.ToInt32(majorVersionString);

if (majorVersion >= 14)
Outlook.Inspector inspector = Globals.ThisAddIn.Application.ActiveInspector();
Microsoft.Office.Tools.Ribbon.RibbonTab tabToActivate = Globals.Ribbons[inspector].Ribbon1.MyCustomTab;

if (string.Equals(ActivePageName, "MyCustomFormRegion"))

Note that different Office applications apparently return differently formatted Application.Version strings. For example, on my computer Word 2010 returns “14.0”, but Outlook 2010 returns “”. To deal with these differences in a consistent way, the code above uses String.Split to extract the “major” version number out of this string (the number before the first period).

*This is the default behavior in projects that target the .NET Framework 4. If you change the Embed Interop Types property of a PIA reference in your project from True to False, the type information for that PIA is no longer embedded, and the add-in will be effectively bound to the specific PIA (or a later version) that is referenced. In other words, a Word 2010 add-in cannot be loaded in Word 2007, etc.


McLean Schofield

  • Hi,

    Great news! Kudos to the VSTO Team for all the improvements in VSTO 4.0.

    Kind regards,


  • OK - you can save the client from requiring to install the PIAs with .NET 4.0 but if you target .NET 4.0 your client needs to install VSTO with Office 2010!  Whereas if your target .NET 3.5 with Office 2010 you don't need to make the client install the VSTO (as it is installed ready for 3.5) but you do need the PIAs.  So either case you need to get the client to install one additional module.  Swings and roundabouts....

  • You are correct in that if you target the .NET Framework 4 and Office 2010, you must deploy the Visual Studio 2010 Tools for Office runtime with your solution (this is not the case when targeting the .NET Framework 3.5 and Office 2010). However, you can include the Visual Studio 2010 Tools for Office runtime redistributable with your setup package when you use ClickOnce or Windows Installer/MSI to deploy your solution. This is the same as with previous versions of VSTO. Is there a particular problem in terms of the VSTO solution installation experience that you're hoping to avoid by including the VSTO runtime redistributable with your solution's installation package?

  • Thanks for the clarfication.  I'm just trying to figure out the best way to write an add-in that targets Office 2007 and 2010 (32-bit and 64-bit) which has the minimal download requirements for most users.  My add-in is a 1MB download by itself and when developed under VS2008 targeting .NET 2.0 for Excel 2007 requires no additional downloads by the user other than them installing Excel .NET Programability from the Control Panel - is this the same as VSTO + PIA (either or both)?

    If I switch to .NET 4 the user's installation experience is more painful for the majority, involving a 50MB+ download.

  • I have VS2010 and Office 2007 on my box (no 2010) and I create a new PowerPoint add-in for 2010. It can't run when pressing F5 because it says "You cannot debug or run this project, because the required version of the Microsoft Office application is not installed." Must I have 2010 on box to even create solutions targetted at 2010/2007?

  • Otaku,

    you can change Visual Studio to open Office 2010 instead of Office 2007. see and just change the path to point to Office 2010 rather than Office 2007.


  • Actually im working on vsto tools addin if u hve any code pls passs me

  • Thanks for this article.  I have VS2010 and want to deploy add-in to Outlook 2007 (and have other projects that require Office 2010 so don't want to remove).  I wrote an Outlook add-in as a test.  It works as designed in Outlook 2010 but when I try to deploy to Outlook 2007 it seems to install OK but doesn't run on start-up and I can't see it when I look in the Trust Center / Add-ins.

    What tools are there available to diagnose what is going wrong?  My registry entries seem to have been deployed OK and the files seem to have been deployed?

    Thanks for any help you can give.  I know this is an old article.


  • Hi Rob,

    Please go to Add-In setup project -> right click -> view -> Registry

    Check for every registry key - if registry setting property has any condition.

    if yes please remove the condition and then build and install.

    Note: make sure you have installed PIA (Primary Interop Assembly) for Outlook 2007

Page 1 of 1 (9 items)

Creating an Add-in for Office 2007 and Office 2010 that "Lights Up" on Office 2010 (McLean Schofield)