Office Development with Visual Studio : Mary Lee

Can I deploy my and all of its prerequisites in one file? (Mary Lee)

VSTO Team — Wed, 14 Oct 2009 22:16:01 GMT

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:

Microsoft Office 2003 solutions with dependencies on .NET Framework 2.0, Visual Studio Tools for Office 2005 SE runtime, Microsoft Office 2007 primary interop assemblies.
Microsoft Office 2007 solutions with dependencies on .NET Framework 3.5 , Visual Studio Tools for Office runtime 3.0, Microsoft Office 2007 primary interop assemblies.
Microsoft Office 2007 solutions with dependencies on .NET Framework 3.5 SP1, Visual Studio Tools for Office runtime 3.0 SP1, Microsoft Office 2007 primary interop assemblies.
Microsoft Office 2007 solutions with dependencies on .NET Framework 3.5 SP1 Client Profile, Visual Studio Tools for Office runtime 3.0 SP1, Microsoft Office 2007 primary interop assemblies.
Really, any WinForms/WPF/console/whatever app with dependencies on .NET Framework, SQL Server Express, SQL Server compact, Visual C++ runtime, Windows Installer, or anything else.

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.

Nested Installations cannot share components.
An administrative installation cannot contain a nested installation.
Patching and upgrading will not work with nested installations.
The installer will not correctly cost a nested installation.
Integrated ProgressBars cannot be used with nested installations.
Resources that are to be advertised cannot be installed by the nested installation.
A package that performs a nested installation of an application should also uninstall the nested application when the parent product is uninstalled.

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:

Do not consume merge modules of vendors who do not promise to fix their merge modules promptly when bugs arrive
Be prepared to handle the heat when bugs are found in your merge module causing issues for others’ products that have consumed your merge module and you get to put out the flame

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.

Demonstrating how to sync Facebook events to Outlook

VSTO Team — Wed, 05 Aug 2009 19:59:07 GMT

Every once in a while, we learn of neat apps that have been created with the Office development tools in Visual Studio. In an Outlook 2007 add-in, Jake Ginnivan combined WPF and the Facebook API to respond to Facebook events from a Ribbon. In addition, this add-in works in Outlook 2010 and has been deployed with ClickOnce. He’s written about this in two parts:

Writing a Facebook event synchroniser for Outlook 2007+ Part 1

Writing a Facebook event synchroniser for Outlook 2007+ Part 2

If you have come across other VSTO apps, feel free to leave a link in a comment here.

Mary Lee, Programming Writer.

Quick Videos of Visual Studio 2010 Features (Beth Massi, Mary Lee)

VSTO Team — Mon, 03 Aug 2009 21:38:55 GMT

If you’ve missed them, Kathleen has been interviewing writers on various documentation teams on some of the new features going into Visual Studio 2010. Our own Mary Lee now has a couple video interviews posted on new VSTO features that you should check out:

If you like reading better than watching videos, here are the walkthroughs in the MSDN library:

For more resources and information on how to download the VS2010 Beta, visit the Visual Studio Developer Center.

Enjoy,
-Beth Massi, Visual Studio Community

Video Interview: Mary Lee on Deploying Multiple Office Solutions (Kathleen McGrath)

VSTO Team — Fri, 05 Jun 2009 05:35:12 GMT

Mary Lee recently posted a blog entry that describes Deploying Multiple Office Solutions in a Single Installer, complete with graphics to help you visualize the process. I recently interviewed Mary to learn more about this topic, and to have her give a demonstration of some of the tasks described in this post.

If you’ve often wondered who’s hidden behind that motorcycle helmet, be sure to check out the video!

See video: Deploying Multiple Office Solutions in a Single ClickOnce Installer

I will be posting additional interviews, demonstrations, and featured Visual Studio 2010 Beta 1 content on my blog: http://blogs.msdn.com/kathleen.

-- Kathleen

Learning about Visual Studio 2010 and .NET Framework 4 (Mary Lee)

VSTO Team — Fri, 22 May 2009 18:29:23 GMT

To learn more about Visual Studio 2010 and .NET Framework 4, Kathleen McGrath is highlighting new documentation about these products with a weekly blog post and a daily tweet. If you want to learn more about the new features and scenarios, check out her blog at http://blogs.msdn.com/kathleen and her twitter feed at http://twitter.com/kathleenmcgrath.

Mary Lee, Programming Writer.

Copying a Document to the End User Computer after a ClickOnce Installation (Mary Lee)

VSTO Team — Thu, 21 May 2009 20:00:00 GMT

Starting in Visual Studio 2010 Beta 1, you can perform additional tasks after an Office solution is installed known as a post-deployment action. For example, you can copy a customized Office document and create registry keys on the end user computer. You can compare these to Windows Installer custom actions.

The Visual Studio Tools for Office runtime supports the ability to perform post-deployment actions after an Office solution is installed. However, Visual Studio does not generate the necessary sections of the ClickOnce application and deployment manifests to perform these actions. To run these post-deployment actions, you must modify the application and deployment manifests. This process is demonstrated in the Walkthrough: Copying a Document to the End User Computer after a ClickOnce Installation topic in the MSDN Library.

The walkthrough uses an Excel workbook project, but this example uses a Word document project for demonstration purposes.

Creating a New Project

1. Create a new Word document-level project that targets the .NET Framework 3.5 named FabrikamWordDocument.

2. Add code to the FabrikamWordDocument project.

3. Build the project.

Creating a Class Library Project that Defines the Post-Deployment Action

1. Create a class library called FileCopyPDA.

2. Add references to Microsoft.VisualStudio.Tools.Applications.Runtime.v10.0 and Microsoft.VisualStudio.ToolsApplications.ServerDocument.v10.0.

3. Rename the class to FileCopyPDA.

4. Replace the FileCopyPDA class with the following code that completes the following tasks:

Copies the Word document file to the user's desktop if the solution is installed or updated.

Changes the _AssemblyLocation property from a relative path to a fully qualified path for the deployment manifest. This is done using the AddCustomization and RemoveCustomization methods.

Deletes the file if the solution is uninstalled.

Public Class FileCopyPDA
    Implements IAddInPostDeploymentAction

    Sub Execute(ByVal args As AddInPostDeploymentActionArgs) Implements IAddInPostDeploymentAction.Execute
        Dim dataDirectory As String = "Data\FabrikamWordDocument.docx"
        Dim file As String = "FabrikamWordDocument.docx"
        Dim sourcePath As String = args.AddInPath
        Dim deploymentManifestUri As Uri = args.ManifestLocation
        Dim destPath As String = Environment.GetFolderPath(Environment.SpecialFolder.DesktopDirectory)
        Dim sourceFile As String = System.IO.Path.Combine(sourcePath, dataDirectory)
        Dim destFile As String = System.IO.Path.Combine(destPath, file)

        Select Case args.InstallationStatus
            Case AddInInstallationStatus.InitialInstall, AddInInstallationStatus.Update
                File.Copy(sourceFile, destFile)
                ServerDocument.RemoveCustomization(destFile)
                ServerDocument.AddCustomization(destFile, deploymentManifestUri)
                Exit Select
            Case AddInInstallationStatus.Uninstall
                If File.Exists(destFile) Then
                    File.Delete(destFile)
                End If
                Exit Select
        End Select
    End Sub

End Class

5. Build the FileCopyPDA project.

6. Add a reference to FileCopyPDA.dll in the FabrikamWordDocument project.

7. Create a directory called “Data” in the FabrikamWordDocument project.

8. Add the FabrikamWordDocument.docx file to the Data folder.

9. In Properties window for the FabrikamWordDocument.docx file, change the Build Action property to Content, and change the Copy to Output Directory property to Copy if newer.

10. Publish the FabrikamWordDocument project. This example uses the c:\publish directory.

Modifying the Application Manifest

1. Open the C:\publish\Application Files\FabrikamWordDocument_1_0_0_0\FabrikamWordDocument.dll.manifest file in the XML Editor in Visual Studio.

2. Add the following XML code after the </vstav3:update> element to run the FileCopy post-deployment action.

<vstav3:postActions>
  <vstav3:postAction>
    <vstav3:entryPoint
      class="FileCopyPDA.FileCopyPDA">
      <assemblyIdentity
        name="FileCopyPDA"
        version="1.0.0.0"
        language="neutral"
        processorArchitecture="msil" />
    </vstav3:entryPoint>
    <vstav3:postActionData>
    </vstav3:postActionData>
  </vstav3:postAction>
</vstav3:postActions>

Re-signing the Manifests

To prove that yes, you really meant to make these changes to the application manifest, you must re-sign the application manifest with a certificate. Then, re-sign and update the deployment manifest to point to the new application manifest.

1. Copy your certificate to the C:\publish\Application Files\FabrikamWordDocument_1_0_0_0 directory. In this example, I’m reusing the temporary certificate created by Visual Studio because I’ll be installing this to a test computer. For production deployment, we recommend that you use a certificate obtained from a certificate authority.

2. In a Visual Studio command prompt, change to the C:\publish\Application Files\FabrikamWordDocument_1_0_0_0 directory. (You may have to open the command prompt in Administrator mode to re-sign the files in the c:\publish directory.)

3. Re-sign the application manifest with the following command:

mage -sign FabrikamWordDocument.dll.manifest -certfile FabrikamWordDocument_TemporaryKey.pfx

4. Change to the c:\publish directory

5. Re-sign the deployment manifest with the following command (on one line):

mage -update FabrikamWordDocument.vsto

–appmanifest "Application Files\FabrikamWordDocument_1_0_0_0\FabrikamWordDocument.dll.manifest"

-certfile "Application Files\FabrikamWordDocument_1_0_0_0\FabrikamWordDocument_TemporaryKey.pfx"

6. Copy the c:\publish\FabrikamWordDocument.vsto file to the c:\publish\Application Files\FabrikamWordDocument_1_0_0_0 directory.

Testing the Installer

1. Copy the c:\publish directory to a test computer.

2. In the c:\publish directory, run the Setup.exe file or double-click FabrikamWordDocument.vsto.

3. Verify that FabrikamWordDocument appears in the Add/Remove Programs list in Windows XP or Programs and Features in Windows Vista.

4. Verify that the FabrikamWordDocument.docx file appears on the desktop.

5. Open the Word document file to verify that your code is running.

Feel free to leave comments and feedback about this new scenario at the bottom of this article.

Happy deployment!

Mary Lee, Programming Writer.

Deploying Multiple Office Solutions In a Single Installer (Mary Lee)

VSTO Team — Wed, 20 May 2009 20:00:00 GMT

Starting in Visual Studio 2010 Beta 1, you can deploy multiple Office solutions in a single ClickOnce installer. For example, you can develop two Office solutions (one for Outlook and another for Excel) and combine these into a single installer with a single entry in the Add/Remove Programs list in Windows XP and the Programs and Features list in Windows Vista.

The Visual Studio Tools for Office runtime supports the ability to deploy multiple Office solutions in a single installer. However, Visual Studio still generates the ClickOnce application and deployment manifests for individual deployment. To deploy multiple Office solutions in a single installer, you must modify the application and deployment manifests to install multiple assemblies. This process is demonstrated in the Walkthrough: Deploying Multiple Office Solutions in a Single ClickOnce Installer topic in the MSDN Library.

Creating Multiple Office Solutions

To continue the example mentioned in the introduction, you can develop an Excel workbook project and an Outlook add-in project for .NET Framework 3.5. Then, to deploy both of these, create an installer project, which you can re-use later to add a third or fourth project. By keeping this installer project separate, it’s possible to keep the original files for the individual projects intact. In this example, the installer project is based on a Word document project, but the document isn’t being deployed. The following figure shows Solution Explorer with three projects, one installer project and two projects to deploy to end user computers.

Publishing the Office Solutions

After you add your code to the Excel and Outlook projects, publish the ContosoExcelWorkbook, ContosoOutlookAddIn, and then ContosoInstaller projects (in that order) to a folder on the development computer. You can right-click on the projects in Solution Explorer, and then click Publish. In this example, the publish directory is c:\publish.

Modifying the Application Manifest

Visual Studio generates an application manifest and deployment manifest for each project. The ClickOnce application manifest is a description of all the files included in the project. Additionally, this file describes how the Office application could load the assembly and run your code. By modifying the application manifest, you can describe files from multiple projects and install all specified projects. There are three different sections of the application manifest to modify: install dependencies, entry points, and assemblies.

These changes may appear lengthy, but it really amounts to a few copy-paste operations and adding four words to the application manifest.

Adding the Install Dependencies

1. In the c:\publish\Application Files folder, copy the contents of the ContosoExcelWork_1_0_0_0 and ContosoOutlookAddIn_1_0_0_0 folder into the ContosoInstaller_1_0_0_0 folder.

2. From the c:\publish\Application Files\ContosoInstaller_1_0_0_0 folder, open the three .dll.manifest files in the XML editor in Visual Studio.

3. Copy the <dependency> block for the Office customization assembly from the ContosoOutlookAddIn.dll.manifest and ContosoExcelWorkbook.dll.manifest files into the ContosoInstaller.dll.manifest file. This code specifies that the ContosoOutlookAddIn.dll and ContosoExcelWorkbook.dll files are part of the ContosoInstaller project.

4. Delete the <dependency> block for the ContosoInstaller.dll. This file is not part of the project, because you are only using the ContosoInstaller project to generate the application manifest template.

Adding the Entry Points

1. In the ContosoInstaller.dll.manifest file, delete the text between the <vstav3:entryPointsCollection> and </vstav3:entryPointsCollection> elements.

2. In the ContosoOutlookAddIn.dll.manifest and ContosoExcelWorkbook.dll.manifest files, copy the text between the <vstav3:entryPointsCollection> and </vstav3:entryPointsCollection> elements and paste them into the ContosoInstaller.dll.manifest file.

3. Add an id to the <vstav3:entryPoints> elements.

Adding the assemblies

1. In the ContosoInstaller.dll.manifest file, delete the text between the <vstov4:customizations xmlns:vstov4="urn:schemas-microsoft-com:vsto.v4"> and </vstov4:customizations> elements.

2. In the ContosoOutlookAddIn.dll.manifest and ContosoExcelWorkbook.dll.manifest files, copy the <vstov4:customizations xmlns:vstov4="urn:schemas-microsoft-com:vsto.v4"> and </vstov4:customizations> elements and paste them into the ContosoInstaller.dll.manifest file.

3. Add the id name to the <vstov4:customization> elements.

4. Save the changes in the ContosoInstaller.dll.manifest file, and close the ContosoExcelWorkbook.dll.manifest and ContosoOutlookAddIn.dll.manifest files.

Re-Signing the Manifests

1. Copy your certificate to the c:\publish\Application Files\ContosoInstaller_1_0_0_0 directory. In this example, I’m reusing the temporary certificate created by Visual Studio because I’ll be installing this to a test computer. For production deployment, we recommend that you use a certificate obtained from a certificate authority.

2. In a Visual Studio command prompt, change to the c:\publish\Application Files\ContosoInstaller_1_0_0_0 directory. (You may have to open the command prompt in Administrator mode to re-sign the files in the c:\publish directory.)

3. Re-sign the application manifest with the following command:

mage -sign ContosoInstaller.dll.manifest -certfile ContosoInstaller_TemporaryKey.pfx

4. Change to the c:\publish directory

5. Re-sign the deployment manifest with the following command (on one line):

mage -update ContosoInstaller.vsto

-appmanifest "Application Files\ContosoInstaller_1_0_0_0\ContosoInstaller.dll.manifest"

-certfile "Application Files\ContosoInstaller_1_0_0_0\ContosoInstaller_TemporaryKey.pfx"

6. Copy the c:\publish\ContosoInstaller.vsto file to the c:\publish\Application Files\ContosoInstaller_1_0_0_0 directory.

Testing the Installer

1. Copy the c:\publish directory to a test computer.

2. In the publish directory, run the Setup.exe file or double-click ContosoInstaller.vsto.

3. Verify that ContosoInstaller appears in the Add/Remove Programs list in Windows XP or Programs and Features in Windows Vista.

4. Open the Excel workbook file and Outlook to verify that your code is running.

Feel free to leave comments and feedback about this new scenario at the bottom of this article.

Happy deployment!

Mary Lee, Programming Writer.

Showcasing the VSTO Power Tools… (Mary Lee)

VSTO Team — Wed, 08 Apr 2009 01:34:00 GMT

The latest .NET Rocks! TV video includes an interview with Beth Massi where she shows how to use the VSTO Power Tools! Also, she introduces some other minor features that you may have heard of: Open XML SDK and LINQ.

Check out Beth’s summary of the video and her demo at her blog: dnrTV: Showing off the Open XML SDK and LINQ.

Mary Lee, Programming Writer.

Deploying Office Solutions with Visual Studio 2008 SP1 and Windows Installer (Mary Lee)

VSTO Team — Wed, 18 Mar 2009 18:36:44 GMT

In Deploying Office Solutions with a Setup Project (Mary Lee), you read about how to deploy Visual Studio Tools for Office solutions with Windows Installer (.msi) in Visual Studio 2008. With Visual Studio 2008 Service Pack 1, the steps are the same: add the project output to the Setup project, add registry keys, sign the application and deployment manifests, and so on.

However if you are using launch conditions to verify that the prerequisites are installed, you must update the launch condition to look for the VSTO 3.0 SP1 runtime.

In the Deploying a Visual Studio Tools for the Office System 3.0 Solution for the 2007 Microsoft Office System Using Windows Installer (Part 1 of 2) whitepaper, look at the To configure launch conditions procedure. Change step 6c from this:

Set the value of RegKey to Software\Microsoft\vsto runtime Setup\v9.0.21022

to the following:

Set the value of RegKey to Software\Microsoft\vsto runtime Setup\v9.0.30729

We are working to update the whitepaper to reflect both of these registry keys. If you have questions about the whitepapers, please visit the Visual Studio Tools for Office MSDN Forum to search for answers and ask your questions.

Happy deployment!

Mary Lee, Programming Writer.

Deploying Documents to a SharePoint Document Library (Mary Lee)

VSTO Team — Sat, 14 Mar 2009 02:56:00 GMT

When you are done developing your customized Microsoft Excel 2007 or Microsoft Word 2007 document-level project in Visual Studio 2008, you may want to publish it to a SharePoint document library for others to use from the SharePoint site, or they can copy the file from the site to their desktop to use locally. In either case, the customization assembly cannot be stored in the SharePoint document library, so you have to configure the workbook to store the assembly on a file share.

In Solution Explorer, right-click the Excel document-level project, and then click Publish. You'll see the Publish Wizard appear.

In the first page of the Publish Wizard, type the folder name where you want Visual Studio to copy the files, known as the publish location. In this case, it's a subfolder of the project folder.

In the second page of the Publish Wizard, type the folder name where the installation files will be located. In this example, the installation files are located on a configure the workbook to look for the assembly on a file share, known as the install location.

Note: You could have set the publish location to this file share in step 1 if you have access rights to the file share. Setting the install location separate from the publish location allows you to publish the files locally and then hand the files over to an IT administrator to upload the files to a file share.

The third and last page of the Publish Wizard is a summary of the publish options.

Copy the publish folder from step 1 to the file share, and upload the Excel workbook file to a SharePoint document library.

The final step is to trust the location of the SharePoint document library to the Trusted Location in Excel. Copy the URL of the SharePoint document library and remove the last Forms/Allitems.aspx text from the URL. For example, if your SharePoint document library is http://sharepoint/sites/writers/SampleDocLibrary/Forms/AllItems.aspx, the location to add to Excel is http://sharepoint/sites/writers/SampleDocLibrary.

1. Open Excel.

2. Click the Microsoft Office button.

3. Click Excel Options.

4. Click Trust Center.

5. Click Trust Center Settings.

6. Click Trusted Locations.

7. Check Allow Trusted Locations on my network.

8. Click Add new location.

9. In the Microsoft Office Trusted Location dialog box, in the Path textbox, type or paste the URL to the SharePoint document library. In this example, it's http://sharepoint/sites/writers/SampleDocLibrary.

10. Click OK to close the Microsoft Office Trusted Location dialog box.

11. Click OK to close the Trust Center dialog box.

12. Click OK to close the Excel Options dialog box.

Finally, open the Excel workbook file from the SharePoint document library. This starts the installation process for the Excel solution. Depending on the security settings, you may see the Microsoft Office Customization Installer dialog box prompting you to install the Excel solution.

This is the blog version of the following topic in the MSDN Library: How to: Deploy a Document-Level Office Solution to a SharePoint Server (2007 System). You can also see the video demonstration at Video How to: Deploy a Document-Level Office Solution to a SharePoint Server (2007 System).

Happy deployment!

Mary Lee, Programming Writer.

Video How Do I: Add Controls at Run Time in an Application-Level Project (Mary Lee)

VSTO Team — Tue, 10 Mar 2009 18:59:52 GMT

In Walkthrough: Adding Controls to a Worksheet at Run Time in an Application-Level Project, you can see to add host controls at run time in an application-level add-in by using Visual Studio 2008 SP1. This video is posted to the How Do I Videos - Visual Basic page, part of the Visual Basic Developer Center.

How Do I: Add Controls to a Worksheet at Run Time in an Application-Level Project?

Mary Lee, Programming Writer.

Best Practices for Deployment with Visual Studio 2008 SP1 (Mary Lee, Rachel Schaw)

VSTO Team — Tue, 03 Feb 2009 02:01:00 GMT

After you develop Office solutions with Visual Studio Tools for Office, you can use Visual Studio 2008 SP1 to simplify your deployment experience. First, you can take advantage of the smaller .NET Framework Client Profile to decrease download time. Next, the Office 2007 primary interop assemblies (PIAs) are included in-the-box with VS2008 SP1 to avoid having to generate bootstrapper manifests. Finally, you can also troubleshoot any installation problems with the event viewer.

Develop your Office 2007 solutions against the .NET Framework Client Profile. The large size of the .NET Framework 3.5 SP1 can lead to long download times. The .NET Framework Client Profile is only 25MB in size, so download times are reduced when installing from the component vendor's web site. For more information about how to configure your solution to use the .NET Framework Client Profile, see How to: Target a Specific .NET Framework.

Deploying the Office 2007 primary interop assemblies is now (mostly) hassle-free. Visual Studio 2008 SP1 includes the Office 2007 PIAs as part of the update. This relieves you from having to download the PIA installer, download a code sample that contains the bootstrapper manifests, move the manifests to a certain directory, compile the ComponentCheck.cpp file to verify that the correct version of Microsoft Office is installed, and dance the hula. Instead, developing with one of the Visual Studio Tools for Office project templates already marks the Microsoft Office 2007 primary interop assemblies as a prerequisites. All you have to do is right-click on the project in Solution Explorer and click Publish.

Troubleshooting the installation and deployment process is more transparent. Any errors that occur are now logged in the event viewer. For example, I deliberately installed the same Office solution twice to generate the following error in the event viewer. Developers commonly see this error when they build and debug an Office solution on their development computer, and then try to install the Office solution on the same development computer. To avoid this problem, use a different account to test the installer on the development computer, or use a different test computer. For more information about the event viewer, see Event Logging (2007 System).

Visual Studio 2008 SP1 also introduced ClickOnce manifests that do not need to be signed. However, Visual Studio Tools for Office relies on signed manifests to identify the publisher and determine if the Office solution is trusted. Optional signing is a feature in VS2008 SP1 that does not apply to Office developers. For more information about trusting Office solutions, see Granting Trust to Office Solutions (2007 System).

Mary Lee, Programming Writer.

Rachel Shaw, Program Manager.

New "How Do I" Video on Creating Smart Tags in Word (Beth Massi)

VSTO Team — Thu, 18 Dec 2008 20:00:00 GMT

Our very own Mary Lee has got a new video up on the Dev Center on programming smart tags in with custom recognizers in Word using Visual Studio 2008 Service Pack 1. This is a video version of the How To topic in the MSDN library.

Watch or download the video here.

Thanks Mary!

Enjoy,
-Beth Massi, Visual Studio Community

Deploying Office 2003 Solutions with Windows Installer (Mary Lee)

VSTO Team — Thu, 18 Dec 2008 02:08:05 GMT

You may want to develop Microsoft Office 2003 solutions with Visual Studio Tools for Office (VSTO) in Visual Studio 2008 SP1 for several reasons.

Your customers are using Microsoft Office 2003.
Your customers are using both Microsoft Office 2003 and the 2007 Microsoft Office system.
Your customers are using .NET Framework 2.0 and cannot migrate to .NET Framework 3.5.

Once you're done with development, you'll want to deploy your Microsoft Office 2003 solutions to your end users. This process involves the following steps:

Check for and install the following prerequisites: .NET FX 2.0, VSTO 2005 SE runtime, and the Microsoft Office primary interop assemblies. If your client computers already have the prerequisites, or you want to do this manually, you can skip this step.
Copy the customization assembly to the end user computer.
Grant full trust to the customization assembly.
For application-level add-ins only, create a set of registry keys so that the Office application knows to load the add-in.

Due to customer demand, I've created five deployment samples that demonstrate these steps. Step 1 is demonstrated in two ways: you can select your prerequisites through the Prerequisites Dialog Box to be installed with the Setup.exe bootstrapper; alternatively, you can configure launch conditions in the Setup project to only install the customization if the prerequisites already exist.

Prerequisites Dialog Box:

Launch Conditions editor:

You can use the Setup project to complete step 2 by copying the customization assembly and for document-level projects, the document or workbook, to the designated installation location. This is done by adding the project output with the File System Editor. The default installation location in these Setup projects is %PROGRAMFILES%\MyCompany\<Name of Setup Project>.

File System Editor:

Full trust is granted by using the SetSecurity project for step 3. This code uses a custom action in the Setup project to create a code access security policy that creates a solution code group for your Office solution, and an assembly code group for the customization assembly.

Custom Actions Editor:

Step 4 only applies to application-level add-ins: when you use the Excel 2003 add-in or Word 2003 add-in project templates, there is a Setup project automatically added to your Office solution that already creates the registry keys documented in Registry Entries for Application-Level Add-Ins.

Registry Editor:

The process of preparing the development computer for deployment and configuring the Setup project is written out step-by-step in the following two whitepapers:

Deploying Visual Studio 2005 Tools for the Office System SE Solutions Using Windows Installer (Part 1 of 2)

Deploying Visual Studio 2005 Tools for the Office System SE Solutions Using Windows Installer: Walkthroughs (Part 2 of 2)

Now, it's time to experiment on your own. Download the sample code and the completed installers from the MSDN Code Gallery: http://code.msdn.microsoft.com/VSTO2005SEMSI

Happy deployment!

Mary Lee, Programming Writer.

How to Include .NET Framework 3.5 SP1 with Your Installer (Mary Lee)

VSTO Team — Wed, 19 Nov 2008 01:55:00 GMT

Recently in the Visual Studio Tools for Office forum, a Visual Studio 2008 SP1 developer asked how to include the .NET Framework 3.5 Service Pack 1 in the same directory as the application. For example, you can select Download prerequisites from the same location as my application in the Prerequisites Dialog Box if your application is going out on CD and being installed without a network connection.

However, when you try to build your setup project or ClickOnce installer, you see the following error message: "The install location for prerequisites has not been set to 'component vendor's web site' and the file 'DotNetFX35SP1\dotNetFX20\netfx20a_x86.msi' in item '.NET Framework 3.5 SP1' can not be located on disk. "

What does it mean? The installers for .NET Framework 3.5 SP1 were not included in the VS2008 SP1 installer due to size restrictions. The default deployment experience is to download the .NET Framework 3.5 SP1 from the Microsoft Download Center during installation.

How do you include the .NET Framework 3.5 SP1? You can download the full .NET Framework 3.5 SP1 installer and extract the necessary files to the Visual Studio bootstrapper directory. After you modify the product.xml file and update the PublicKey value, the .NET Framework 3.5 SP1 will appear in the Prerequisites Dialog Box. You can find the full instructions in the Visual Studio 2008 Service Pack 1 Readme in section 2.3.1.1 Enable Samesite for the .NET Framework 3.5 SP1 bootstrapper package.

While these steps may seem lengthy, you only have to complete the steps once on your development computer. Then, every project you develop and deploy can include .NET Framework 3.5 SP1 as a prerequisite.

If you have further questions about deployment, visit the ClickOnce and Setup & Deployment MSDN forum to search for answers or ask your questions.

Happy deployment!

Mary R Lee, programming writer.