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.

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

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

UPDATE FROM MARCH 06, 2013:

We heard your feedback! With the latest release of the Office Developer Tools for Visual Studio 2012, you no longer need to manually create a bootstrapper package.

Just make sure to enable the bootstrapper under the "Publish" dialog's "Prerequisites" settings:

============ Original Post from December 2012 ============

At the SharePoint Conference last month, Preview 2 of the Office Developer Tools for Visual Studio 2012 was announced. The release offers a number of enhancements for VSTO developers: in particular, design-time support for Office 2013, and the ability to develop Add-Ins that target the .NET 4.5 Framework. Preview 2 also includes tooling for the new Apps for Office and Apps for SharePoint projects, Workflow enhancements, VSTA improvements, and much more. See the official announcement to share in the exciting news, or skip straight to downloading the tools.

Here is just a snippet of the VSTO portion of the announcement:

New in this release, Visual Studio Tools for Office (a.k.a. VSTO add-ins) now have design time and runtime support that target Office 2013 and .NET Framework 4.5. This has been a much-requested feature. We also fixed the top customer reported issues in the VSTO runtime for Office 2013. We’re looking forward to hearing your feedback!

Out of the box, Office 2010 SP1 and Office 2013 include a VSTO Runtime version that’s sufficient to run .NET 4.0 add-ins. Thus, if you’re targeting .NET 4.0 – whether or not you install Preview 2 on top of Visual Studio 2012 – customers with Office 2010 SP1 and higher will be able to run your add-ins without any additional installation. If you want to leverage the new .NET 4.5 support and/or ensure that your customers have the latest runtime (which includes some cumulative bug fixes), you will need to follow the steps below to create a Bootstrapper package.

First, create a folder in a convenient location, and name it “VSTOR40”. Eventually, you’ll move this folder to a particular location under “Program Files”, but you may want to place it on your Desktop or “My Documents” for now. That way, you won’t be required to run everything as administrator in order to create or edit files.

As you step through this process, it may help to keep a high-level overview of the end-result in mind. As shown in the image below, you’ll end up with a “VSTOR40” folder that contains “product.xml” and an “en” sub-folder, which in turn contains “eula.1033.txt” and “package.xml”.

Let’s start with product.xml. Create a new file, and copy-paste the following contents into it:

<?xmlversion="1.0"encoding="utf-8" ?>

<Product

  xmlns="http://schemas.microsoft.com/developer/2004/01/bootstrapper"

  ProductCode="Microsoft.VSTORuntime.4.0">

  <RelatedProducts>

    <EitherProducts>

      <DependsOnProductCode="Microsoft.Net.Client.3.5" />

      <DependsOnProductCode=".NETFramework,Version=v4.0,Profile=Client" />

      <DependsOnProductCode=".NETFramework,Version=v4.5,Profile=Client" />

    </EitherProducts>

  </RelatedProducts>

  <!-- Defines the list of files to be copied on build. -->

  <PackageFilesCopyAllPackageFiles="false">

    <PackageFileName="vstor_redist.exe"HomeSite="VSTORRedist"PublicKey="3082010a0282010100baa4496c10fb229c65a216983bcb6162fa7429ad8d0619d27158198a5e570d69626e36a04efd2279e01dc71a618efafca3112516c8c0582c318a88ae321e88db7f3e7457f785a43653ca41ef69b8699e6d56eb6ee4b2264d73d16471b41fd66184880021ef6858835b498fb4dfd335d6cbd9309f53fc7a6b9a842bb7216774d4f678b6618798947c2acf67e919bed9ba63ed3c4e3e7d02ebf37fafcf0fb7817ef4fbe8f79148bb8f3d8cc807931cf3bd75e4fc6320299f39f34154381e546440b484aa37aef3008ce20dfaa1b20f22b5a7a9aed617b930f002232010fa6b590fe0ad9f9e608193034c0d9b6219b3bb96bc915aa67886769b6ccd4cec12b538470203010001"/>

  </PackageFiles>

  <InstallChecks>

    <RegistryCheckProperty="VSTORuntimeVersionInstalled"Key="HKLM\SOFTWARE\Microsoft\VSTO Runtime Setup\v4R"Value="Version"/>

  </InstallChecks>

  <!-- Defines how to run the Setup package. -->

  <CommandsReboot="Defer">

    <Command

      PackageFile="vstor_redist.exe"

      Arguments=" /q /norestart"

      EstimatedInstalledBytes="2600000"

      EstimatedTempBytes="4500000"

      EstimatedInstallSeconds="60">

      <InstallConditions>

        <BypassIfProperty="VSTORuntimeVersionInstalled"Compare="VersionGreaterThanOrEqualTo"Value="10.0.40303"/>

        <!-- Requires the user to be an admin user when installing the prerequisite -->

        <FailIfProperty="AdminUser"Compare="ValueEqualTo"Value="false"String="AdminRequired"/>

      </InstallConditions>

      <ExitCodes>

        <ExitCodeValue="0"Result="Success"/>

        <ExitCodeValue="1641"Result="SuccessReboot"/>

        <ExitCodeValue="3010"Result="SuccessReboot"/>

        <DefaultExitCodeResult="Fail"FormatMessageFromSystem="true"String="GeneralFailure" />

      </ExitCodes>

    </Command>

  </Commands>

</Product>

Now create an “en” folder, and a file named “package.xml” within it. Into that file, copy-paste the following text:

<?xmlversion="1.0"encoding="utf-8" ?>

<Package

  xmlns="http://schemas.microsoft.com/developer/2004/01/bootstrapper"

  Name="DisplayName"

  Culture="Culture"

  LicenseAgreement="eula.1033.txt">

  <PackageFiles>

    <PackageFileName="eula.1033.txt"/>

  </PackageFiles>

  <!-- Defines a localizable string table for error messages. -->

  <Strings>

    <StringName="DisplayName">Microsoft Visual Studio 2010 Tools for Office Runtime (x86 and x64)</String>

    <StringName="Culture">en</String>

    <StringName="AdminRequired">Administrator permissions are required to install the Microsoft Visual Studio 2010 Tools for Office Runtime (x86 and x64). Contact your administrator.</String>

    <StringName="GeneralFailure">A failure occurred attempting to install the Microsoft Visual Studio 2010 Tools for Office Runtime (x86 and x64).</String>

    <StringName="VSTORRedist">http://go.microsoft.com/fwlink/?LinkId=158918</String>

  </Strings>

</Package>

Finally, for “eula.1033.txt” (the end-user license agreement for the VSTO Runtime), you can simply re-use the same Eula that shipped with the VSTO Runtime (and which you got on your machine when you installed “Preview 2” of the office tools).

To find that file, simply navigate to one of the following locations:

x64 versions of Windows:

• C:\Program Files\Common Files\microsoft shared\VSTO\10.0\Microsoft Visual Studio 2010 Tools for Office Runtime (x64)

X86 versions of Windows:

• C:\Program Files\Common Files\microsoft shared\VSTO\10.0\Microsoft Visual Studio 2010 Tools for Office Runtime (x86)

And copy the “eula.1033.txt” file from there into your “VSTOR40\en” folder.

Almost there! Now all that remains is to copy the folder into the appropriate location on your machine (the same machine you’ll be using to publish the project). To do this:

1) Locate the Bootstrapper packages folder. On a machine where you’ve installed Visual Studio 2012, the default installation locations should be:

x64 version of Windows:

• C:\Program Files (x86)\Microsoft SDKs\Windows\v8.0A\Bootstrapper\Packages

x86 version of Windows:

• C:\Program Files\Microsoft SDKs\Windows\v8.0A\Bootstrapper\Packages

If the folder is not there, you can determine the location by looking it up in the registry – see http://msdn.microsoft.com/en-us/library/ms165429.aspx for more information.

 

2) Move your VSTOR40 folder into the Bootstrapper packages folder that you’ve identified above. In the end, your path and folder structure should look like this:

You’re done! After you close and re-open Visual Studio, you should be able to activate the VSTO Runtime Bootstrapper prerequisite. To do this, open your project, go to the project’s properties, and then navigate to the “Publish” tab. Under the “Install Settings” group, click on the “Prerequisites…” button. In the window that opens, set the checkmark next to

“Microsoft Visual Studio 2010 Tools for Office Runtime (x86 and x64)”.

That’s it! After you publish your solution, end-users who don’t have the VSTO Runtime will automatically get the latest version of the runtime from the web.

Questions? Comments? Don’t hesitate to ask.

~ Michael Zlatkovsky | Program Manager, Visual Studio Tools for Office & Apps for Office

I'm pleased to announce that the official Office Developer Tools for Visual Studio 2012 is now available to download! For VSTO developers, this release brings .NET 4.5 support and design-time support for Office 2013, along with general design-time enhancements and bug fixes to the VSTO Runtime (released separately a few months ago via our download center and Windows Update; see KB 2796590 for information regarding the Runtime). We also heard your feedback from "Preview 2" of the tools, including the request to bring back the VSTO Runtime Bootstrapper into VS 2012 -- it is now back in the product.

Office Developer Tools for Visual Studio 2012 also includes tooling for the new apps for Office and apps for SharePoint projects, improvements to SharePoint Workflows, and more. You can read the official announcement for apps-related tooling on Soma’s blog post.

VSTO Office 2013 design-time support in Visual Studio 2012.

Note: Now that's we've added .NET 4.5 support to 2013, we've properly re-categorized the templates in the "New Project" dialog according to the .NET framework version that they support. So, if you're looking for the Office 2010 templates after installing the latest tools, be sure to adjust the ".NET Framework" dropdown to ".NET Framework 4.0". Again, to recap, both the 2010 and 2013 templates support .NET Framework 4.0, but only the 2013 templates support .NET Framework 4.5 -- and the "New Project" dialog respects that categorization.

I hope you enjoy using our new tools! If you have any questions or comments, please don't hesitate to reach out to us.

- Michael Zlatkovsky | Program Manager, Visual Studio Tools for Office & Apps for Office

Note:  This post is simultaneously published both to the VSTO blog and to the apps for Office blog.  To learn more about apps for Office, visit http://dev.office.com.

With all the buzz around the new apps for Office programming model, developers might be wondering: What benefits does the new app model bring, and which of the three technology choices―apps for Office, managed VSTO add-ins, or VBA macros―are best suited for particular scenarios?

Apps for Office is a recognition that the technology landscape around us is changing: that ubiquitous connectivity, mobile devices, powerful and personalized cloud services, real time collaboration, and social are fast becoming the norm, and that a new app model must be brought forth to capture these evolving needs. At the same time, however, it’s important to note that all three technologies will be supported in the foreseeable future. This means that if you have an existing VBA or VSTO project, and if you’re satisfied with the capabilities, tooling, and marketability of your existing solution, you can be confident that your investments are safe. However, if you’re looking to expand the exposure of your product or service to a larger audience and allow for greater monetization opportunities, apps for Office can be a great option to start looking into. This post will guide you through the strengths of each of the three technologies, and suggest some factors by which to choose which Office customization approach is right for you.

Apps for Office

The newest addition to the Office developer toolbox, apps for Office are a new way for users to interact with Office customizations. Instead of having to install add-ins or enable macros, users can download, install, and use apps alongside a document, message, or appointment straight from the Office Store or from an internal corporate app catalog, and those apps run in a protected sandbox environment. Built with web technologies, apps for Office are particularly well suited for creating web mash-ups and using Office as a surface for exposing existing web functionality. Apps also offer lifecycle management capabilities, such as distributing or removing apps for the users in your corporation, managing updates, and tracking telemetry.

Figure 1 shows a content app and a task pane app embedded within an Excel document. The apps expose the existing web services of Bing Maps and Merriam-Webster, respectively, surfacing these through a convenient app that interacts with the user’s Excel environment.

Figure 1. Apps for Office: A content app and a task pane app embedded within an Excel document

The friction-free ease of distribution is a huge draw for apps for Office. Additionally, the Office Store is designed to make it easy for you to monetize your apps. Another neat aspect is that apps for Office can be used both in the Office 2013 and in a growing selection of Office Web Apps as well. For example, a mail app can use the same JavaScript API calls both for the desktop Outlook client and for Outlook Web App, spanning a breadth of devices. Most importantly, due to the web-based approach of the apps for Office model, developers can use their existing coding skills to develop apps with virtually any web programming technology, and apps can connect to virtually any backend data store. This makes the transition to the apps for Office model easier and smoother for web developers, allowing folks to re-use their existing web services and web development skills.

The sweet spot for apps―connecting rich web content and services contextually with Office―offers great public exposure and a host of deployment and web-technology benefits. The additional benefit that is exclusively available with apps for Office is the potential to monetize your app by making it available for purchase in the Office Store. Additionally, companies can lock down access to any internally-built apps by using a corporate app catalog that is only accessible to internal users. These two features offer great potential for both app distribution and IT management that has not been available to Office developers and enterprises in the past.

Managed add-ins built with Visual Studio Tools for Office (VSTO)

Visual Studio Tools for Office uses the .NET Framework to customize and extend Office. VSTO offers the full language support of C# and Visual Basic, and can therefore leverage the same frameworks, tools, and programming paradigms as the rest of the .NET Framework. VSTO also provides very tight integration with the Office client applications, both in terms of the rich sets of APIs, and the customizability of the user interface.

The following figure shows a VSTO solution running in PowerPoint. Notice the customized ribbon, the custom task pane (built with Windows Presentation Foundation), and a free-floating Windows Forms window.

Figure 2. A VSTO solution running in PowerPoint

For developers and businesses that need to leverage more extensive customizability of Office, or that need to target Office 2007 or 2010 (apps are only available starting in Office 2013), VSTO is the primary option. In addition to UI customization, VSTO excels at automation scenarios, such as adding or modifying shapes or charts, manipulating or merging documents on the user’s behalf, and interacting with other programs or resources on the host computer. Of course, not all automation-like tasks require automation: inserting a new paragraph with formatting, for example, could be done with VSTO through automation, or it could be done with apps for Office by writing out an Open-XML formatted string. The exact technology choice, and the suitability of using apps for automation, would depend on carefully analyzing the business requirements and the user workflow for the application.

VSTO is not lightweight, however. Deploying a VSTO add-in requires users to install the application, much as they would install any other desktop application. This often requires that the IT organization be involved in determining how safe the add-in is to the existing corporate environment, as well as often requiring that IT determine the upgrade path of this add-in for future releases of Office, and other application and environmental dependencies. This can lengthen time-to-deploy and create maintenance dependencies for the IT and business organizations. It is also important to note that VSTO add-ins run with the same security privileges as any other desktop program. This is a double-edged sword: it allows VSTO to use the power of the host computer and interact with the file system, which might be necessary for working across documents or interacting with external programs; but it also means that a malicious add-in could compromise the computer security. Even a well-intentioned add-in might affect the performance or stability of the host Office application, leading to slower startup or application failures. Ultimately, it’s up to the user (or IT admin) to ensure that an add-in is trustworthy before installing it. At the end of the day, VSTO is a very powerful tool, but this power does come at a cost.

Visual Basic for Applications (VBA) macros

VBA and the Visual Basic Editor is a tool that offers an in-product experience for automating Office client applications. Rooted in “classic” Visual Basic 6, and with support for a macro recorder in Word, Excel, and Access, VBA offers a simple onramp for writing an Office automation task to get the job done. However, as a decade-old technology, VBA is also more limited in terms of UI customizability and the overall tooling and framework support.

Figure 3. The VBA programming environment (built on “classic” Visual Basic 6) that is included with Office

An important distinction to note with VBA is that the customization code gets stored directly in the document. This makes initial deployment and distribution very easy, but makes updating code within any existing documents much more difficult. Within a corporate environment, this can create IT management and governance issues, as there is really no way to manage the proliferation of copies of the documents among users. Office documents are often emailed and duplicated, so there may have hundreds or thousands of documents based on the same VBA macro. Updating the code to improve features or to fix bugs would require that the Office artifact be re-emailed, re-structured, and re-worked by every single user and in every single file that has been using the customization. In a corporate environment, with no management or governance around such solutions, this is a risk to consider when creating or deploying VBA solutions.

In summary, VBA is the “classic” option for creating document-based customizations―particularly for programs that will require little upkeep, and which will be distributed to a fairly limited internal/departmental set of audience. Writing a 10,000-line program in VBA, or selling the program as a standalone product, would be more of a stretch.

Here is a comprehensive look at the choice of tools, across a broad set of categories:

*: Indicates a dimension where support might be partial today, but where future investments are expected to be made.

**: Relies on standard web offlining capabilities (for example, AppCache, Web Storage, page caching) supported by the browser.

Summary

Given the increasing array of choices―apps for Office vs. add-ins vs. macros―it is important for developers to know the value of each tool. Add-ins and macros are existing forms of solutions, aimed at solving existing needs for existing users, and will continue to be supported on the desktop for the foreseeable future. Apps for Office, meanwhile, come with a forward-looking platform, aimed at bringing web services and web technologies closer to Office developers. For add-ins and macros, Office is a highly-customizable, but siloed platform; for apps, Office is more of an integrated surface for exposing loosely-coupled web functionality using the web technology of your choice, with the potential for monetization, IT governance, and ease of lifecycle management and deployment. Both approaches have their merits, with add-ins and macros providing robust interaction and automation of existing Office client applications, and with apps for Office better-suited for creating easily-deployable, web-based solutions that work across a growing base of platforms including desktop, web and mobile. In cases where multiple approaches are equally possible, apps for Office are a natural choice for new projects.

Just like comparing Windows 8 apps with traditional Win32 desktop applications, or redesigning traditional websites for mobile devices, apps for Office represent a paradigm shift from add-ins and macros. In many cases, converting an existing managed add-in to the new apps for Office model would require significant re-imagining of the application. Thus, instead of thinking of a 1-for-1 conversion, it might be more fruitful to enable a few key scenarios using apps for Office, and see where that leads. Perhaps those key scenarios are enough to gain business on their own; or perhaps the re-imagined app can lead to entirely new scenarios and services, based on the cloud-optimized and multi-platform nature and the huge potential of the new app model. The capabilities of the new app model will continue to evolve, so even if your scenario does not fit the scope of the new app model today, keep an eye out for the new features of tomorrow.

Happy coding―with whatever Office technology(ies) you choose! Please leave a comment if you have any questions. (You may also want to check the apps for Office cross-post to see other users’ comments).

―Michael Zlatkovsky | Program Manager, Visual Studio Tools for Office and Apps for Office

Special thanks to Sonya Koptyev, Jim Nakashima, Rolando Jimenez Salgado, Sean Laberee, Angela Chu-Hatoun, and Sudheer Maremanda for their input into this post.

For those who've been following the announcements at BUILD these past two days, Visual Studio 2013 Preview has now been officially released.

For Office developers, the VS 2013 Preview release means that the Office 2013 design-time support and the .NET 4.5 support that previously required a separate download is now integrated into Visual Studio alongside the existing Office 2010 and .NET 4.0 support. Better yet, we've also added runtime and design-time support for the new .NET Framework 4.5.1 Preview. If you're interested to learn more about the .NET Framework 4.5.1 Preview — which includes exciting new features like better async debugging, function return values in the debugger, performance improvements, and more, see "Announcing the .NET Framework 4.5.1 Preview".

We hope you enjoy Visual Studio 2013 Preview and the exciting new features of .NET 4.5.1!

~ Michael Zlatkovsky | Program Manager, Visual Studio Tools for Office & Apps for Office

We are pleased to announce the release of Visual Studio 2013!  This latest release offers many great features for developers, such as innovative IDE features like Peek and CodeLens, expanded ALM capacities with Git support, enhancements for ASP.NET web development, and much more.

Visual Studio 2013 also delivers a broad set of tooling for the new apps for Office and apps for SharePoint.  Some highlights include the ability to create MVC SharePoint apps, enhancements around app-publishing, and a new set of tooling around Cloud Business Apps that integrate seamlessly with Office 365 services.  Learn more on the apps for Office and SharePoint blog.

Tip:  Just like Visual Studio 2012, Visual Studio 2013 continues to support the Office 2010 templates.  However, to reduce clutter, we have re-categorized the project templates according to the .NET Framework version that they support.  So, if you're looking for the Office 2010 templates, be sure to adjust the ".NET Framework" dropdown to ".NET Framework 4.0", as shown below:

We hope you enjoy Visual Studio 2013 and the many great features that this IDE has to offer!

~ Michael Zlatkovsky | Program Manager, Visual Studio Tools for Office & Apps for Office

We are pleased to announce a new version of the VSTO Runtime (10.0.50325) that addresses two important issues reported to us by customers.

For VSTO add-ins using WPF controls, customers using touch-enabled devices experienced a 15-20 second lag when closing Office applications. This issue was first reported via a Connect bug, which helped provide the context for investigating and fixing this bug.

Additionally, for developers using SHA256 code-signing certificates, the installation Trust Prompt would erroneously display “Unknown Publisher” even when the publisher was fully trusted.  The latest update ensures that the publisher’s name and verification status are properly displayed.

As always, the latest version of the VSTO Runtime is available for download at http://go.microsoft.com/fwlink/?LinkId=140384.  The update will also be distributed as part of Windows Update in the future. If you would like to ensure that your users have the latest version installed, please follow the instructions for creating/modifying a bootstrapper package from our previous blog post, substituting the latest version number (10.0.50325) into the following properties:

<BypassIf Property="VSTORuntimeVersionInstalled" Compare="VersionGreaterThanOrEqualTo" Value="10.0.50325"/>

<BypassIf Property="VSTORuntimeVersionOfficeInstalled" Compare="VersionGreaterThanOrEqualTo" Value="10.0.50325"/>

We would like to thank our customers who brought these issues to our attention.

~ Thomas Bombach | Software Development Engineer, Visual Studio

[Guest Post by Marty Andren, Premier Field Engineer at Microsoft]

As a Microsoft Premier Field Engineer / Office Developer, a question I’m often asked when helping customers develop VSTO solutions is how to customize the user interface when building out their application. This question is not as simple as it sounds, as the approach used will vary depending on which version of Visual Studio you are using, and which version of Office you are targeting for your particular application. There are a number of good references available on MSDN that address this very topic. I’ve listed out a couple of these below:

• Using Visual Studio 2013 (or 2012) to target Office 2010 or Office 2013
• Using Visual Studio 2010 to target Office 2007 or Office 2010

One area in particular where developers new to VSTO want a deeper understanding is how to work with ribbons and ribbon controls. When creating custom ribbons for a VSTO application, it’s generally easiest to start with the VSTO Ribbon Designer (unless you have a compelling need to use Ribbon XML for advanced functionality like overriding default Office commands or customizing the backstage). Adding a ribbon to your VSTO project is simple. As can be seen in the screenshot below, simply right click on the project in Solution Explorer, select Add > New Item, and choose Ribbon (Visual Designer) from the list of available options.

Having added a ribbon (and in the case of Outlook, having defined where it will show up), you can start dragging additional controls from the toolbox to customize the ribbon to meet your needs. Also note that converting a visual ribbon to an xml ribbon within Visual Studio is a very simple thing to do. Once you’ve completed customizing the visual ribbon in the designer window, simply right click on the ribbon in the designer, and select “Export to XML” from the popup menu.

Regardless of the type of ribbon added to the project, understanding how to define the icons presented on the controls contained in that ribbon is another area developers new to VSTO struggle with. In general, there are two possible options for doing this type of customization:

1. Adding your own custom icons to your solution, and referencing them on the controls using the Image property.
2. Leveraging the vast library of icons provided with Microsoft Office through the use of the OfficeImageId property.

The latter approach tends to be more commonly used, both because you don’t have to generate your own icons, and because the Office provided icons will look more natural inside of an Office application. As developers learn fairly quickly however, finding the right ID for the icon you wish to use can be a bit of a challenge. This is further complicated by the fact that the icon / id combinations can vary slightly from one version of Office to another (In general, the Office product team tries to keep the Id’s consistent from version to version to help ensure backward compatibility as new versions of Office are released, however there are times when an Id needs to be changed as the product evolves). To help developers out with this, Microsoft has published a couple useful resources that catalog all of the icons for a particular version of Office. I’ve listed out where to find these below:

• Office 2010 Add-In: Icons Gallery (Can also be used with Office 2013)
• Office 2007 Add-In: Icons Gallery

To see this in action, let’s work with the following example: Say your app exposes functionality to delete a report, and you want to use one of the standard Office images. You review the options in one of the icon galleries mentioned above, and decide that the Sheet Delete icon fits your needs nicely. To utilize this icon in a ribbon button of your application, you would select the button in the designer window, and from within the Properties window set the OfficeImageId to the ID of the image you’re looking to use (in this case, conveniently named “SheetDelete”):

It’s important to note that in the Ribbon Designer in Visual Studio, the button will just show up with a placeholder, but it will be replaced with the correct icon at runtime:

Note also that the same icon can be specified in Ribbon XML by setting the imageMso attribute as follows:

<button id="Button1" imageMso="SheetDelete" label="Delete Report" />

In addition to working with custom controls, there may also be times where you want to access the built-in controls in an Office application (to hide or disable a particular button on the ribbon for example). Finding the ID of the particular control in question can be as challenging as looking for the appropriate icon ID described above. Fortunately, Microsoft has published a few resources to help developers out in this area as well:

• Office 2013 Help Files: Office Fluent User Interface Control Identifiers
• Office 2010 Help Files: Office Fluent User Interface Control Identifiers
• 2007 Office System Document: Lists of Control IDs
• And, of course, the interactive "Icons Gallery" links from above (copying here for easy reference):
• Office 2010 Add-In: Icons Gallery (Can also be used with Office 2013)
• Office 2007 Add-In: Icons Gallery 

Let me close by saying that I would encourage VSTO developers to download all of these resources / reference materials, regardless of whether they are new or experienced in this space. I’ve found all of these to be extremely useful when developing VSTO solutions and I trust you will too.

Marty Andren
Microsoft
Premier Field Engineer, Office Developer Lead
US PFE – East Region

In a VSTO Runtime release earlier this year, we addressed an issue of slow application shutdown for add-ins using WPF controls on touch-enabled devices. With the release of .NET Framework 4.5.2 two months ago, and the increased usage of our latest runtime “in the wild”, we received customer feedback that the latest .NET 4.5.2 version interacts negatively with our latest VSTO Runtime version, introducing a different application shutdown issue.

Today, we’re happy to announce that we’ve quickly turned around a fix in the release of VSTO Runtime version 10.0.50701.  The update is cumulative, and includes both the previous fixes (addressing the touch-screen scenario) and the additional compatibility with .NET Framework 4.5.2.

As always, the latest version of the VSTO Runtime is available for download at http://go.microsoft.com/fwlink/?LinkId=140384.  The update will also be distributed as part of Windows Update in the upcoming months.  If you would like to ensure that your users have the latest version installed, please follow the instructions for creating/modifying a bootstrapper package from a previous blog post, substituting the latest version number (10.0.50701) into the following properties:

<BypassIf Property="VSTORuntimeVersionInstalled" Compare="VersionGreaterThanOrEqualTo" Value="10.0.50701"/>

<BypassIf Property="VSTORuntimeVersionOfficeInstalled" Compare="VersionGreaterThanOrEqualTo" Value="10.0.50701"/>

Again, many thanks to the developer community for bringing the issue to our attention, and helping us resolve this in a timely manner.

~ Michael Zlatkovsky | Program Manager, Visual Studio

Earlier today, Visual Studio 2013 Update 3 was released.  This update offers a number of small but useful enhancements for VSTO developers:

#1:  Support for .NET 4.5.2 and beyond, and the de-coupling of Office versions from .NET versions.

We heard a lot of feedback on this on MSDN forums, with developers asking to mix-and-match versions of Office with versions of .NET Framework.  With the latest update, the .NET Framework and Office versions are fully de-coupled:  both the Office 2010 and 2013 project templates can work with any of the 4.0+ .NET Framework versions (.NET 4.0, 4.5, 4.5.1, 4.5.2, and beyond).

#2:  Better design-time support for SHA256 code-signing certificates.

In the past, using a SHA256 code-signing certificate would require a runtime dependency on having .NET Framework 4.5 or above installed on the runtime machine.  Running the program without .NET 4.5 installed would result in an error:  “Exception reading manifest …  System.Deployment.Application.InvalidDeploymentException: Manifest XML signature is not valid. ---> System.Security.Cryptography.CryptographicException: SignatureDescription could not be created for the signature algorithm supplied.”

With the latest update, Visual Studio now generates a manifest in a way that can be read and run by .NET 4.0, even if the certificate happens to be SHA256.

#3:  Easier unit-testing.

One question I’ve often heard is about unit-testing VSTO projects.  Part of the confusion was caused by VSTO projects not appearing in the “Add Reference” dialog.  Unit-testing VSTO projects would therefore require creating a separate class library project, moving code into it, and then referencing this class library from both the VSTO project and the Unit Test project.  While this separation made sense for complex projects, it was overkill if all you wanted was to unit-test a handful of classes and methods.

Starting with VS 2013 Update 3, the “Add References” restriction for VSTO projects has been removed:  you can now create a Unit Test project and reference the VSTO project directly, without the intermediary step of moving your code to a separate class library project.

We hope you find these updates a welcome addition to your Visual Studio 2013 experience.  And, of course, for those interested in the new apps for Office & SharePoint model or in the Office 365 APIs, there’s a variety of tooling enhancements and platform capabilities that went into Visual Studio 2013 Update 2 a few months back (and included in this cumulative Update 3).  Check out http://dev.office.com or the Office Dev Blog for more information.

- Michael Zlatkovsky | Program Manager, Visual Studio

In the VSTO Runtime released a month and a half ago (version 10.0.50701), a small regression was inadvertently introduced, which is fixed in today’s update to the runtime.

The issue impacts add-ins that call Globals.Factory.GetVSTOObject on a Word document or Excel workbook.  If Windows Presentation Foundation (WPF) is used for the add-in's user interface, and if the document or workbook corresponding to the "GetVSTOObject" function call is closed, the WPF UI Thread may shut down prematurely.  When this happens, rendering for WPF controls will be broken until Excel or Word restarted.  While this issue only manifests itself on certain system configurations (primarily touch-enabled devices) and only under very particular conditions, we recognize that this can be a serious scenario-blocker for certain add-ins.  Today, we are releasing a new version (10.0.50903) of the runtime that takes all the enhancements of the previous VSTO runtime release, but resolves this particular issue.

The update is cumulative and can be installed both on a clean machine and on top of an existing VSTO runtime installation.  As always, the latest VSTO runtime can be downloaded from our “permalink” at http://go.microsoft.com/fwlink/?LinkId=140384.  The update will also be distributed as part of Windows Update in the upcoming months.  In the meantime, if you would like to ensure that your users have the latest version installed, please follow the instructions for creating/modifying a bootstrapper package from a previous blog post, substituting the latest version number (10.0.50903) into the following properties in product.xml:

<BypassIf Property="VSTORuntimeVersionInstalled" Compare="VersionGreaterThanOrEqualTo" Value="10.0.50903"/>

<BypassIf Property="VSTORuntimeVersionOfficeInstalled" Compare="VersionGreaterThanOrEqualTo" Value="10.0.50903"/>

~ Michael Zlatkovsky | Program Manager, Visual Studio

UPDATE from July 2014:  INSTRUCTIONS FOR UPDATING AN EXISTING BOOTSTRAPPER:

On the build machine (which might be the same as your development machine), open the “product.xml” file under

C:\Program Files (x86)\Microsoft SDKs\Windows\v8.1A\Bootstrapper\Packages\VSTOR40

For “Program Files (x86)”, substitute “Program Files" in you’re on a 32-bit operating system.

For “v8.1A” (which is the location used by VS 2013), substitute:

• “v8.0A” for Visual Studio 2012
• “v7.0A” for Visual Studio 2010

Once you have found the file, replace the existing version number with the desired version in the following properties:

<BypassIf Property="VSTORuntimeVersionInstalled" Compare="VersionGreaterThanOrEqualTo" Value="10.0.50701"/>

<BypassIf Property="VSTORuntimeVersionOfficeInstalled" Compare="VersionGreaterThanOrEqualTo" Value="10.0.50701"/>

(Be sure to substitute the latest version number, based on the file information available at http://go.microsoft.com/fwlink/?LinkId=140384).

==============================================

UPDATE FROM MARCH 06, 2013:

We heard your feedback! With the latest release of the Office Developer Tools for Visual Studio 2012 (and subsequently in Visual Studio 2013), you no longer need to manually create a bootstrapper package.

Just make sure to enable the bootstrapper under the "Publish" dialog’s "Prerequisites" settings:

============ Original Post from December 2012 ============

At the SharePoint Conference last month, Preview 2 of the Office Developer Tools for Visual Studio 2012 was announced. The release offers a number of enhancements for VSTO developers: in particular, design-time support for Office 2013, and the ability to develop Add-Ins that target the .NET 4.5 Framework. Preview 2 also includes tooling for the new Apps for Office and Apps for SharePoint projects, Workflow enhancements, VSTA improvements, and much more. See the official announcement to share in the exciting news, or skip straight to downloading the tools.

Here is just a snippet of the VSTO portion of the announcement:

New in this release, Visual Studio Tools for Office (a.k.a. VSTO add-ins) now have design time and runtime support that target Office 2013 and .NET Framework 4.5. This has been a much-requested feature. We also fixed the top customer reported issues in the VSTO runtime for Office 2013. We’re looking forward to hearing your feedback!

Out of the box, Office 2010 SP1 and Office 2013 include a VSTO Runtime version that’s sufficient to run .NET 4.0 add-ins. Thus, if you’re targeting .NET 4.0 – whether or not you install Preview 2 on top of Visual Studio 2012 – customers with Office 2010 SP1 and higher will be able to run your add-ins without any additional installation. If you want to leverage the new .NET 4.5 support and/or ensure that your customers have the latest runtime (which includes some cumulative bug fixes), you will need to follow the steps below to create a Bootstrapper package.

First, create a folder in a convenient location, and name it “VSTOR40”. Eventually, you’ll move this folder to a particular location under “Program Files”, but you may want to place it on your Desktop or “My Documents” for now. That way, you won’t be required to run everything as administrator in order to create or edit files.

As you step through this process, it may help to keep a high-level overview of the end-result in mind. As shown in the image below, you’ll end up with a “VSTOR40” folder that contains “product.xml” and an “en” sub-folder, which in turn contains “eula.1033.txt” and “package.xml”.

Let’s start with product.xml. Create a new file, and copy-paste the following contents into it:

<?xml version="1.0" encoding="utf-8" ?>

<Product

  xmlns="http://schemas.microsoft.com/developer/2004/01/bootstrapper"

  ProductCode="Microsoft.VSTORuntime.4.0">

  <RelatedProducts>

    <EitherProducts>

      <DependsOnProduct Code="Microsoft.Net.Client.3.5" />

      <DependsOnProduct Code=".NETFramework,Version=v4.0,Profile=Client" />

      <DependsOnProduct Code=".NETFramework,Version=v4.5,Profile=Client" />

    </EitherProducts>

  </RelatedProducts>

  <!– Defines the list of files to be copied on build. –>

  <PackageFiles CopyAllPackageFiles="false">

    <PackageFile Name="vstor_redist.exe" HomeSite="VSTORRedist" PublicKey="3082010a0282010100baa4496c10fb229c65a216983bcb6162fa7429ad8d0619d27158198a5e570d69626e36a04efd2279e01dc71a618efafca3112516c8c0582c318a88ae321e88db7f3e7457f785a43653ca41ef69b8699e6d56eb6ee4b2264d73d16471b41fd66184880021ef6858835b498fb4dfd335d6cbd9309f53fc7a6b9a842bb7216774d4f678b6618798947c2acf67e919bed9ba63ed3c4e3e7d02ebf37fafcf0fb7817ef4fbe8f79148bb8f3d8cc807931cf3bd75e4fc6320299f39f34154381e546440b484aa37aef3008ce20dfaa1b20f22b5a7a9aed617b930f002232010fa6b590fe0ad9f9e608193034c0d9b6219b3bb96bc915aa67886769b6ccd4cec12b538470203010001"/>

  </PackageFiles>

  <InstallChecks>

    <RegistryCheck Property="VSTORuntimeVersionOfficeInstalled" Key="HKLM\SOFTWARE\Microsoft\VSTO Runtime Setup\v4" Value="Version"/>

    <RegistryCheck Property="VSTORuntimeVersionInstalled" Key="HKLM\SOFTWARE\Microsoft\VSTO Runtime Setup\v4R" Value="Version"/>

  </InstallChecks>

  <!– Defines how to run the Setup package. –>

  <Commands Reboot="Defer">

    <Command

      PackageFile="vstor_redist.exe"

      Arguments=" /q /norestart"

      EstimatedInstalledBytes="2600000"

      EstimatedTempBytes="4500000"

      EstimatedInstallSeconds="60">

      <InstallConditions>

        <BypassIf Property="VSTORuntimeVersionInstalled" Compare="VersionGreaterThanOrEqualTo" Value="10.0.50701"/>

        <BypassIf Property="VSTORuntimeVersionOfficeInstalled" Compare="VersionGreaterThanOrEqualTo" Value="10.0.50701"/>

        <!– Requires the user to be an admin user when installing the prerequisite –>

        <FailIf Property="AdminUser" Compare="ValueEqualTo" Value="false" String="AdminRequired"/>

      </InstallConditions>

      <ExitCodes>

        <ExitCode Value="0" Result="Success"/>

        <ExitCode Value="1641" Result="SuccessReboot"/>

        <ExitCode Value="3010" Result="SuccessReboot"/>

        <DefaultExitCode Result="Fail" FormatMessageFromSystem="true" String="GeneralFailure" />

      </ExitCodes>

    </Command>

  </Commands>

</Product>

(Be sure to substitute the latest version number, based on the version information available at http://go.microsoft.com/fwlink/?LinkId=140384).

Now create an “en” folder, and a file named “package.xml” within it. Into that file, copy-paste the following text:

<?xml version="1.0" encoding="utf-8" ?>

<Package

  xmlns="http://schemas.microsoft.com/developer/2004/01/bootstrapper"

  Name="DisplayName"

  Culture="Culture"

  LicenseAgreement="eula.1033.txt">

  <PackageFiles>

    <PackageFile Name="eula.1033.txt"/>

  </PackageFiles>

  <!– Defines a localizable string table for error messages. –>

  <Strings>

    <String Name="DisplayName">Microsoft Visual Studio 2010 Tools for Office Runtime (x86 and x64)</String>

    <String Name="Culture">en</String>

    <String Name="AdminRequired">Administrator permissions are required to install the Microsoft Visual Studio 2010 Tools for Office Runtime (x86 and x64). Contact your administrator.</String>

    <String Name="GeneralFailure">A failure occurred attempting to install the Microsoft Visual Studio 2010 Tools for Office Runtime (x86 and x64).</String>

    <String Name="VSTORRedist">http://go.microsoft.com/fwlink/?LinkId=158918</String>

  </Strings>

</Package>

Finally, for “eula.1033.txt” (the end-user license agreement for the VSTO Runtime), you can simply re-use the same Eula that shipped with the VSTO Runtime (and which you got on your machine when you installed “Preview 2” of the office tools).

To find that file, simply navigate to one of the following locations:

x64 versions of Windows:

• C:\Program Files\Common Files\microsoft shared\VSTO\10.0\Microsoft Visual Studio 2010 Tools for Office Runtime (x64)

X86 versions of Windows:

• C:\Program Files\Common Files\microsoft shared\VSTO\10.0\Microsoft Visual Studio 2010 Tools for Office Runtime (x86)

And copy the “eula.1033.txt” file from there into your “VSTOR40\en” folder.

Almost there! Now all that remains is to copy the folder into the appropriate location on your machine (the same machine you’ll be using to publish the project). To do this:

1) Locate the Bootstrapper packages folder. On a machine where you’ve installed Visual Studio 2012, the default installation locations should be:

x64 version of Windows:

• C:\Program Files (x86)\Microsoft SDKs\Windows\v8.0A\Bootstrapper\Packages

x86 version of Windows:

• C:\Program Files\Microsoft SDKs\Windows\v8.0A\Bootstrapper\Packages

If the folder is not there, you can determine the location by looking it up in the registry – see http://msdn.microsoft.com/en-us/library/ms165429.aspx for more information.

2) Move your VSTOR40 folder into the Bootstrapper packages folder that you’ve identified above. In the end, your path and folder structure should look like this:

You’re done! After you close and re-open Visual Studio, you should be able to activate the VSTO Runtime Bootstrapper prerequisite. To do this, open your project, go to the project’s properties, and then navigate to the “Publish” tab. Under the “Install Settings” group, click on the “Prerequisites…” button. In the window that opens, set the checkmark next to

“Microsoft Visual Studio 2010 Tools for Office Runtime (x86 and x64)”.

That’s it! After you publish your solution, end-users who don’t have the VSTO Runtime will automatically get the latest version of the runtime from the web.

Questions? Comments? Don’t hesitate to ask.

~ Michael Zlatkovsky | Program Manager, Visual Studio Tools for Office & Apps for Office

I’m pleased to announce that the official Office Developer Tools for Visual Studio 2012 is now available to download! For VSTO developers, this release brings .NET 4.5 support and design-time support for Office 2013, along with general design-time enhancements and bug fixes to the VSTO Runtime (released separately a few months ago via our download center and Windows Update; see KB 2796590 for information regarding the Runtime). We also heard your feedback from "Preview 2" of the tools, including the request to bring back the VSTO Runtime Bootstrapper into VS 2012 — it is now back in the product.

Office Developer Tools for Visual Studio 2012 also includes tooling for the new apps for Office and apps for SharePoint projects, improvements to SharePoint Workflows, and more. You can read the official announcement for apps-related tooling on Soma’s blog post.

VSTO Office 2013 design-time support in Visual Studio 2012.

Note: Now that’s we’ve added .NET 4.5 support to 2013, we’ve properly re-categorized the templates in the "New Project" dialog according to the .NET framework version that they support. So, if you’re looking for the Office 2010 templates after installing the latest tools, be sure to adjust the ".NET Framework" dropdown to ".NET Framework 4.0". Again, to recap, both the 2010 and 2013 templates support .NET Framework 4.0, but only the 2013 templates support .NET Framework 4.5 — and the "New Project" dialog respects that categorization.

I hope you enjoy using our new tools! If you have any questions or comments, please don’t hesitate to reach out to us.

- Michael Zlatkovsky | Program Manager, Visual Studio Tools for Office & Apps for Office

Note:  This post is simultaneously published both to the VSTO blog and to the apps for Office blog.  To learn more about apps for Office, visit http://dev.office.com.

With all the buzz around the new apps for Office programming model, developers might be wondering: What benefits does the new app model bring, and which of the three technology choices―apps for Office, managed VSTO add-ins, or VBA macros―are best suited for particular scenarios?

Apps for Office is a recognition that the technology landscape around us is changing: that ubiquitous connectivity, mobile devices, powerful and personalized cloud services, real time collaboration, and social are fast becoming the norm, and that a new app model must be brought forth to capture these evolving needs. At the same time, however, it’s important to note that all three technologies will be supported in the foreseeable future. This means that if you have an existing VBA or VSTO project, and if you’re satisfied with the capabilities, tooling, and marketability of your existing solution, you can be confident that your investments are safe. However, if you’re looking to expand the exposure of your product or service to a larger audience and allow for greater monetization opportunities, apps for Office can be a great option to start looking into. This post will guide you through the strengths of each of the three technologies, and suggest some factors by which to choose which Office customization approach is right for you.

Apps for Office

The newest addition to the Office developer toolbox, apps for Office are a new way for users to interact with Office customizations. Instead of having to install add-ins or enable macros, users can download, install, and use apps alongside a document, message, or appointment straight from the Office Store or from an internal corporate app catalog, and those apps run in a protected sandbox environment. Built with web technologies, apps for Office are particularly well suited for creating web mash-ups and using Office as a surface for exposing existing web functionality. Apps also offer lifecycle management capabilities, such as distributing or removing apps for the users in your corporation, managing updates, and tracking telemetry.

Figure 1 shows a content app and a task pane app embedded within an Excel document. The apps expose the existing web services of Bing Maps and Merriam-Webster, respectively, surfacing these through a convenient app that interacts with the user’s Excel environment.

Figure 1. Apps for Office: A content app and a task pane app embedded within an Excel document

The friction-free ease of distribution is a huge draw for apps for Office. Additionally, the Office Store is designed to make it easy for you to monetize your apps. Another neat aspect is that apps for Office can be used both in the Office 2013 and in a growing selection of Office Web Apps as well. For example, a mail app can use the same JavaScript API calls both for the desktop Outlook client and for Outlook Web App, spanning a breadth of devices. Most importantly, due to the web-based approach of the apps for Office model, developers can use their existing coding skills to develop apps with virtually any web programming technology, and apps can connect to virtually any backend data store. This makes the transition to the apps for Office model easier and smoother for web developers, allowing folks to re-use their existing web services and web development skills.

The sweet spot for apps―connecting rich web content and services contextually with Office―offers great public exposure and a host of deployment and web-technology benefits. The additional benefit that is exclusively available with apps for Office is the potential to monetize your app by making it available for purchase in the Office Store. Additionally, companies can lock down access to any internally-built apps by using a corporate app catalog that is only accessible to internal users. These two features offer great potential for both app distribution and IT management that has not been available to Office developers and enterprises in the past.

Managed add-ins built with Visual Studio Tools for Office (VSTO)

Visual Studio Tools for Office uses the .NET Framework to customize and extend Office. VSTO offers the full language support of C# and Visual Basic, and can therefore leverage the same frameworks, tools, and programming paradigms as the rest of the .NET Framework. VSTO also provides very tight integration with the Office client applications, both in terms of the rich sets of APIs, and the customizability of the user interface.

The following figure shows a VSTO solution running in PowerPoint. Notice the customized ribbon, the custom task pane (built with Windows Presentation Foundation), and a free-floating Windows Forms window.

Figure 2. A VSTO solution running in PowerPoint

For developers and businesses that need to leverage more extensive customizability of Office, or that need to target Office 2007 or 2010 (apps are only available starting in Office 2013), VSTO is the primary option. In addition to UI customization, VSTO excels at automation scenarios, such as adding or modifying shapes or charts, manipulating or merging documents on the user’s behalf, and interacting with other programs or resources on the host computer. Of course, not all automation-like tasks require automation: inserting a new paragraph with formatting, for example, could be done with VSTO through automation, or it could be done with apps for Office by writing out an Open-XML formatted string. The exact technology choice, and the suitability of using apps for automation, would depend on carefully analyzing the business requirements and the user workflow for the application.

VSTO is not lightweight, however. Deploying a VSTO add-in requires users to install the application, much as they would install any other desktop application. This often requires that the IT organization be involved in determining how safe the add-in is to the existing corporate environment, as well as often requiring that IT determine the upgrade path of this add-in for future releases of Office, and other application and environmental dependencies. This can lengthen time-to-deploy and create maintenance dependencies for the IT and business organizations. It is also important to note that VSTO add-ins run with the same security privileges as any other desktop program. This is a double-edged sword: it allows VSTO to use the power of the host computer and interact with the file system, which might be necessary for working across documents or interacting with external programs; but it also means that a malicious add-in could compromise the computer security. Even a well-intentioned add-in might affect the performance or stability of the host Office application, leading to slower startup or application failures. Ultimately, it’s up to the user (or IT admin) to ensure that an add-in is trustworthy before installing it. At the end of the day, VSTO is a very powerful tool, but this power does come at a cost.

Visual Basic for Applications (VBA) macros

VBA and the Visual Basic Editor is a tool that offers an in-product experience for automating Office client applications. Rooted in “classic” Visual Basic 6, and with support for a macro recorder in Word and Excel, VBA offers a simple onramp for writing an Office automation task to get the job done. However, as a decade-old technology, VBA is also more limited in terms of UI customizability and the overall tooling and framework support.

Figure 3. The VBA programming environment (built on “classic” Visual Basic 6) that is included with Office

While application-level solutions are possible in VBA, VBA code is often stored and distributed directly in a document. This makes initial deployment and distribution very easy, but makes updating code within any existing documents much more difficult. Office documents are often emailed and duplicated, so there may have hundreds or thousands of documents based on the same VBA macro. Updating the code to improve features or to fix bugs would require that the Office artifact be re-emailed, re-structured, and re-worked by every single user and in every single file that has been using the customization. Within a corporate environment, this can create IT management and governance issues, as there is really no way to manage the proliferation of copies of the documents among users.   VBA application-level solutions can avoid this issue, since they are not tied to a particular document; but, in so doing they also lose out on the ease of initial distribution as they need to be installed to a particular folder, which can be a challenge for some users. (Note that in a business environment, the IT department can automate the installation via Group Policy).
  
In summary, VBA is the “classic” option for creating Office solutions, usually aimed at an internal/departmental set of audience. Writing a 10,000-line program in VBA, or selling the program as a standalone product, is more of a stretch.

Here is a comprehensive look at the choice of tools, across a broad set of categories:

*: Indicates a dimension where support might be partial today, but where future investments are expected to be made.

**: Relies on standard web offlining capabilities (for example, AppCache, Web Storage, page caching) supported by the browser.

Summary

Given the increasing array of choices―apps for Office vs. add-ins vs. macros―it is important for developers to know the value of each tool. Add-ins and macros are existing forms of solutions, aimed at solving existing needs for existing users, and will continue to be supported on the desktop for the foreseeable future. Apps for Office, meanwhile, come with a forward-looking platform, aimed at bringing web services and web technologies closer to Office developers. For add-ins and macros, Office is a highly-customizable, but siloed platform; for apps, Office is more of an integrated surface for exposing loosely-coupled web functionality using the web technology of your choice, with the potential for monetization, IT governance, and ease of lifecycle management and deployment. Both approaches have their merits, with add-ins and macros providing robust interaction and automation of existing Office client applications, and with apps for Office better-suited for creating easily-deployable, web-based solutions that work across a growing base of platforms including desktop, web and mobile. In cases where multiple approaches are equally possible, apps for Office are a natural choice for new projects.

Just like comparing Windows 8 apps with traditional Win32 desktop applications, or redesigning traditional websites for mobile devices, apps for Office represent a paradigm shift from add-ins and macros. In many cases, converting an existing managed add-in to the new apps for Office model would require significant re-imagining of the application. Thus, instead of thinking of a 1-for-1 conversion, it might be more fruitful to enable a few key scenarios using apps for Office, and see where that leads. Perhaps those key scenarios are enough to gain business on their own; or perhaps the re-imagined app can lead to entirely new scenarios and services, based on the cloud-optimized and multi-platform nature and the huge potential of the new app model. The capabilities of the new app model will continue to evolve, so even if your scenario does not fit the scope of the new app model today, keep an eye out for the new features of tomorrow.

Happy coding―with whatever Office technology(ies) you choose! Please leave a comment if you have any questions. (You may also want to check the apps for Office cross-post to see other users’ comments).

―Michael Zlatkovsky | Program Manager, Visual Studio Tools for Office and Apps for Office

Special thanks to Sonya Koptyev, Jim Nakashima, Rolando Jimenez Salgado, Sean Laberee, Angela Chu-Hatoun, and Sudheer Maremanda for their input into this post.

[July 15, 2013]:  Updated VBA section.

For those who’ve been following the announcements at BUILD these past two days, Visual Studio 2013 Preview has now been officially released.

For Office developers, the VS 2013 Preview release means that the Office 2013 design-time support and the .NET 4.5 support that previously required a separate download is now integrated into Visual Studio alongside the existing Office 2010 and .NET 4.0 support. Better yet, we’ve also added runtime and design-time support for the new .NET Framework 4.5.1 Preview. If you’re interested to learn more about the .NET Framework 4.5.1 Preview — which includes exciting new features like better async debugging, function return values in the debugger, performance improvements, and more, see “Announcing the .NET Framework 4.5.1 Preview“.

We hope you enjoy Visual Studio 2013 Preview and the exciting new features of .NET 4.5.1!

~ Michael Zlatkovsky | Program Manager, Visual Studio Tools for Office & Apps for Office

We are pleased to announce the release of Visual Studio 2013!  This latest release offers many great features for developers, such as innovative IDE features like Peek and CodeLens, expanded ALM capacities with Git support, enhancements for ASP.NET web development, and much more.

For VSTO developers, Visual Studio 2013 comes with in-the-box design-time support for Office 2013, which previously required a separate download.  VSTO also now supports .NET Framework 4.5.1 – which includes exciting better async debugging, function return values in the debugger, performance improvements, and more. 

Visual Studio 2013 also delivers a broad set of tooling for the new apps for Office and apps for SharePoint.  Some highlights include the ability to create MVC SharePoint apps, enhancements around app-publishing, and a new set of tooling around Cloud Business Apps that integrate seamlessly with Office 365 services.  Learn more on the apps for Office and SharePoint blog.

Tip:  Just like Visual Studio 2012, Visual Studio 2013 continues to support the Office 2010 templates.  However, to reduce clutter, we have re-categorized the project templates according to the .NET Framework version that they support.  So, if you’re looking for the Office 2010 templates, be sure to adjust the ".NET Framework" dropdown to ".NET Framework 4.0", as shown below:

We hope you enjoy Visual Studio 2013 and the many great features that this IDE has to offer!

~ Michael Zlatkovsky | Program Manager, Visual Studio Tools for Office & Apps for Office

We are pleased to announce a new version of the VSTO Runtime (10.0.50325) that addresses two important issues reported to us by customers.

For VSTO add-ins using WPF controls, customers using touch-enabled devices experienced a 15-20 second lag when closing Office applications. This issue was first reported via a Connect bug, which helped provide the context for investigating and fixing this bug.

Additionally, for developers using SHA256 code-signing certificates, the installation Trust Prompt would erroneously display “Unknown Publisher” even when the publisher was fully trusted.  The latest update ensures that the publisher’s name and verification status are properly displayed.

As always, the latest version of the VSTO Runtime is available for download at http://go.microsoft.com/fwlink/?LinkId=140384.  The update will also be distributed as part of Windows Update in the future. If you would like to ensure that your users have the latest version installed, please follow the instructions for creating/modifying a bootstrapper package from our previous blog post, substituting the latest version number (10.0.50325) into the following properties:

<BypassIf Property=”VSTORuntimeVersionInstalled” Compare=”VersionGreaterThanOrEqualTo” Value=”10.0.50325“/>

<BypassIf Property=”VSTORuntimeVersionOfficeInstalled” Compare=”VersionGreaterThanOrEqualTo” Value=”10.0.50325“/>

We would like to thank our customers who brought these issues to our attention.

~ Thomas Bombach | Software Development Engineer, Visual Studio

[Guest Post by Marty Andren, Premier Field Engineer at Microsoft]

As a Microsoft Premier Field Engineer / Office Developer, a question I’m often asked when helping customers develop VSTO solutions is how to customize the user interface when building out their application. This question is not as simple as it sounds, as the approach used will vary depending on which version of Visual Studio you are using, and which version of Office you are targeting for your particular application. There are a number of good references available on MSDN that address this very topic. I’ve listed out a couple of these below:

• Using Visual Studio 2013 (or 2012) to target Office 2010 or Office 2013
• Using Visual Studio 2010 to target Office 2007 or Office 2010

One area in particular where developers new to VSTO want a deeper understanding is how to work with ribbons and ribbon controls. When creating custom ribbons for a VSTO application, it’s generally easiest to start with the VSTO Ribbon Designer (unless you have a compelling need to use Ribbon XML for advanced functionality like overriding default Office commands or customizing the backstage). Adding a ribbon to your VSTO project is simple. As can be seen in the screenshot below, simply right click on the project in Solution Explorer, select Add > New Item, and choose Ribbon (Visual Designer) from the list of available options.

Having added a ribbon (and in the case of Outlook, having defined where it will show up), you can start dragging additional controls from the toolbox to customize the ribbon to meet your needs. Also note that converting a visual ribbon to an xml ribbon within Visual Studio is a very simple thing to do. Once you’ve completed customizing the visual ribbon in the designer window, simply right click on the ribbon in the designer, and select “Export to XML” from the popup menu.

Regardless of the type of ribbon added to the project, understanding how to define the icons presented on the controls contained in that ribbon is another area developers new to VSTO struggle with. In general, there are two possible options for doing this type of customization:

1. Adding your own custom icons to your solution, and referencing them on the controls using the Image property.
2. Leveraging the vast library of icons provided with Microsoft Office through the use of the OfficeImageId property.

The latter approach tends to be more commonly used, both because you don’t have to generate your own icons, and because the Office provided icons will look more natural inside of an Office application. As developers learn fairly quickly however, finding the right ID for the icon you wish to use can be a bit of a challenge. This is further complicated by the fact that the icon / id combinations can vary slightly from one version of Office to another (In general, the Office product team tries to keep the Id’s consistent from version to version to help ensure backward compatibility as new versions of Office are released, however there are times when an Id needs to be changed as the product evolves). To help developers out with this, Microsoft has published a couple useful resources that catalog all of the icons for a particular version of Office. I’ve listed out where to find these below:

• Office 2010 Add-In: Icons Gallery (Can also be used with Office 2013)
• Office 2007 Add-In: Icons Gallery

To see this in action, let’s work with the following example: Say your app exposes functionality to delete a report, and you want to use one of the standard Office images. You review the options in one of the icon galleries mentioned above, and decide that the Sheet Delete icon fits your needs nicely. To utilize this icon in a ribbon button of your application, you would select the button in the designer window, and from within the Properties window set the OfficeImageId to the ID of the image you’re looking to use (in this case, conveniently named “SheetDelete”):

It’s important to note that in the Ribbon Designer in Visual Studio, the button will just show up with a placeholder, but it will be replaced with the correct icon at runtime:

Note also that the same icon can be specified in Ribbon XML by setting the imageMso attribute as follows:

<button id="Button1" imageMso="SheetDelete" label="Delete Report" />

In addition to working with custom controls, there may also be times where you want to access the built-in controls in an Office application (to hide or disable a particular button on the ribbon for example). Finding the ID of the particular control in question can be as challenging as looking for the appropriate icon ID described above. Fortunately, Microsoft has published a few resources to help developers out in this area as well:

• Office 2013 Help Files: Office Fluent User Interface Control Identifiers
• Office 2010 Help Files: Office Fluent User Interface Control Identifiers
• 2007 Office System Document: Lists of Control IDs
• And, of course, the interactive "Icons Gallery" links from above (copying here for easy reference):
• Office 2010 Add-In: Icons Gallery (Can also be used with Office 2013)
• Office 2007 Add-In: Icons Gallery 

Let me close by saying that I would encourage VSTO developers to download all of these resources / reference materials, regardless of whether they are new or experienced in this space. I’ve found all of these to be extremely useful when developing VSTO solutions and I trust you will too.

Marty Andren
Microsoft
Premier Field Engineer, Office Developer Lead
US PFE – East Region