If you missed it, Office announced a compatibility program to help IT and developers who have built add-ins make a seamless upgrade to Office 2010. We want you to have a successful and seamless migration to Office 2010 for your VSTO solutions. The program provides tools for environment assessment, code scanning and remediation assistance, and an update to the document conversion tools introduced with Office 2007.
Check out Michael Kiselman’s post for more details on the program that will be available in early December.
Enjoy, -Beth Massi, Visual Studio Community
I have previously posted how you can specify various properties for a VSTO solution like the Publisher and Product Names by tweaking a few files in Visual Studio 2008.
With Visual Studio 2010 (Beta 2) you can edit these properties directly through the Publish Page. All Office projects in Visual Studio 2010 now have an Options button on the Publish Page, which allows you to spet these properties.
The Publish Options dialog is similar to the ClickOnce publish options dialog for other types of projects, but this dialog only displays the options applicable to Office projects.
Here is what these properties mean:
Publisher Name – The name of the Publisher as displayed in Programs and Features
Product Name – The name of the Solution as it will show up in the Programs and Features (Add Remove Programs Entry)
Support URL – A URL which End Users can visit to get support for this particular solution. The support URL shows up as a clickable link for the product name during the installation trust prompt.
Solution Name – (Friendly Name) This is the name of the Add-In as it is displayed in the Office Add-ins dialog.
Office Application Description – The description of the Office Add-in as displayed in the Office Add-ins dialog.
Add-in Load Behavior – Specifies whether the add-in should load when the Office Application Starts up or whether it should load on demand when the end user tries to interact with it. By default all add-ins are set to load at startup of the Office Application but if you care about Office startup performance and don’t want your add-in to be running all the time then you should consider loading it on demand.
Andrew Whitechapel has a post on how an Office add-in can be demand loaded using different loadbehavior values. Previously you had manually update the ClickOnce manifests with the appropriate load behavior value. With Visual Studio 2010 you can set the option to load the add-in on demand and the loadbehavior will be automatically set to 16 (connect first time) –> Load the add-in on startup for the first time and then load on demand from then on.
Loading an add-in on demand can help improve the startup performance of the Office application. It can also reduce the application’s working set as the add-in is not loaded in memory until the end user interacts with it. Setting the add-in to demand load is a good option if your add-in has UI based triggers, like a Ribbon item that the end user can interact with to load the add-in. However demand loading may not be a good option if your add-in is needs to listen to application events like opening a document etc all the time the application is running. So if your add-in doesn’t have to run all the time, then setting it to Load on Demand is a good option to consider.
Lastly, there is an interesting side note for those of you who may have changed their VS 2008 based project files based on my previous post. If you updated the project file using the same property names as that mentioned in the post, you can migrate that project to VS 2010 and continue using those property values. You no longer need the custom targets file as that functionality is now directly available in the Visual Studio common targets.
For more information, see Publishing Office Solutions.
Have fun with Visual Studio 2010 Beta2 and let us know your feedback!
Saurabh
One frequent customer question is about how to deploy an application and all of its prerequisites in a single .msi or .exe file. This question applies whether you are deploying any of the following:
There are three concepts in deployment related to prerequisites: nesting, merging, and chaining or bootstrapping.
Nesting is the process of embedding a Windows Installer file (.msi) within another .msi file. However, the How to create a nested .msi package article has an important disclaimer.
The drawbacks of creating a nested MSI installation are listed in the same article.
For these reasons, nesting is no longer supported.
Merging includes shared code, files, resources, registry entries, and setup logic to applications as a single compound file. Prerequisites available as a merge module (.msm) form can be added to a .msi file. For example, if a prerequisite is available as an .msm, you can add it to a Setup project in Visual Studio as shown in How to: Create or Add a Merge Module Project. However, merge modules cannot be serviced by the same owner as the .msi file, so it is difficult to fix issues in the merge module. Tao of the Windows Installer, Part 4 lists two cautionary notes:
For these reasons, using merge modules is not recommended.
Nesting and merging create a single file to deploy an application and its prerequisites, but these methods are not supported and not recommended. Thus, the answer to the question in the title is no: you cannot or should not deploy an application and its prerequisites in one file.
Chaining or bootstrapping is the process of checking for and installing missing prerequisites, including installing the application that is going to be used to install the rest of the prerequisites and application. You can use Visual Studio to generate a chainer/bootstrapper that is called Setup.exe. This program checks for and installs missing prerequisites before installing the application or Office solution.
If you are deploying an Office 2007 solution in Visual Studio 2008 SP1, the .NET Framework 3.5 SP1, Visual Studio Tools for Office 3.0 SP1 runtime, and Microsoft Office 2007 primary interop assemblies are already selected in the Prerequisites Dialog Box.
To learn more about how to install prerequisites in Visual Studio, see the following topics.
How to: Install Prerequisites on End User Computers to Run Office Solutions
How to: Install Prerequisites in Windows Installer Deployment
How to: Install Prerequisites with a ClickOnce Application
If the prerequisite package does not appear in Visual Studio, you can create your own bootstrapper package. After you create a product.xml file that describes the prerequisite and a package.xml files that includes locale-specific error messages, you can copy the bootstrapper package to \Program Files\Microsoft SDKs\Windows\v6.0A\Bootstrapper\Packages folder. For more information, see Creating Bootstrapper Packages.
Other tools besides Visual Studio: You can also use MSBuild and the GenerateBootstrapper Task to create a bootstrapper on a build computer. Alternatively, you can use the Windows Installer XML Toolset to generate .msi files and package prerequisites. For more information, see http://wix.sourceforge.net/.
For questions about bootstrapping, search for answers or post new questions in the ClickOnce and Setup & Deployment forum.
Happy deployment!
Mary Lee, Programming Writer.
Robert Green, VSTO MVP, has started a series of tutorials on building on Office 2007! Thanks Robert!
In this first of a series of tutorials on building applications on Office you’ll learn how to create an Outlook 2007 customer appointment management solution using Visual Studio 2008. This step-by-step tutorial also includes full source code in Visual Basic and C#. Check out the tutorial on the VSTO Developer Center:
Building an Office Business Application Part 1 - Scheduling Customer Appointments
If you’re just getting started with Office development in Visual Studio, this is a great place to start.
Enjoy!