Office Development with Visual Studio : .NET Framework Client Profile

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.

VSTO and the .NET Framework Client Profile (Christin Boyd)

VSTO Team — Wed, 17 Sep 2008 04:02:05 GMT

One of our loyal blog readers asked if "VSTO officially supports targeting the Client Profile? I did a quick check and it seems to be working fine but it is good if we explicitly mention whether it is supported." The answer is yes. Starting in Visual Studio 2008 Service Pack 1 (SP1), you can develop 2007 Microsoft Office solutions with .NET Framework version 3.5 or .NET Framework Client Profile. The .NET Framework Client Profile is a subset of the full .NET Framework 3.5 that has a size of 25-30 MB. For more information about the .NET Framework Client Profile, see .NET Framework Client Profile.

You can read more about how to target the Client Profile in the localized documentation article "How to: Change the Target .NET Framework"

If you build a solution with the Client Profile, then please let us know by commenting on this page. Does the performance suite your needs? How was the experience?

-Christin Boyd, Program Manager

What's New in VS 2008 SP1 and how the VSTO team decided what to include in a Service Pack (Christin Boyd, Mary Lee)

VSTO Team — Fri, 11 Jul 2008 22:29:00 GMT

Updated August, 2008

I'd like to give you some insight into how we decide what goes into a Service Pack for Microsoft Visual Studio. I'm speaking specifically about how the VSTO team built SP1; most other groups within Visual Studio use the same process.

We take a few different approaches including:

Clearly defining the scope and purpose of the Service Pack
Prioritizing Critical Bugs in our bug database in a large meeting room with many stakeholders and passionate debates
Writing scenarios from the perspective of the user in the form of "I can develop a ..."
Daily triage of all bugs, including bugs that are entered by customers through Connect

In the last few months of product stabilization (which means the last few months before we shipped VS 2008), we make tough decisions to postpone some bugs to the Service Pack (SP). At some point around RTM, we schedule meetings to start prioritizing bugs for the SP.

The Visual Studio division is split into about a dozen Product Units, of which VSTO is a Product Unit. Twenty people from the VSTO unit met to prioritize bugs for the SP. We voiced opinions, quoted customers, demonstrated the bugs, and threw around cost estimates such as "Richard could fix it in three or four days" "No way, that is at least an 8 day work item and the workaround is straight forward!" Debates were often passionate because we are proud of our work, and care deeply about fixing any problems. We had three separate meetings over the course of a month to enable teams to refine their cost estimates and further research solutions. We prioritize on a couple of factors:

Severity: meaning impact to users judged by asking is there a workaround, does it leave the project in an unstable state, or in the worst case does something crash.
Priority: meaning does it impact a core scenario, do customers use this feature often, is it a regression from a previous release.
Cost: how long will it take to fix it and test the fix.
Dependencies: if it requires code changes in Office or the .NET Framework, we would need to negotiate with those teams and their Service Pack teams.

The second way we prioritize and document our Service Pack plans is to write scenarios. We hear feedback from you describing what you want to accomplish with our tools. So we take that feedback and write our feature descriptions using the first-person voice of the customer. We write both tasks and full end-to-end scenarios. If there is a bug that prevents the user from accomplishing the complete scenario, then that is a high priority bug fix for a Service Pack. For example, here are some of the scenarios that we addressed with Service Pack 1 to Visual Studio 2008:

I can add managed controls to a Word document by using an application-level add-in.(including Windows Forms controls and VSTO controls in the Microsoft.Office.Tools.Word namespace)
I can add managed controls to an Excel Workbook by using an application-level add-in.(including Windows Forms controls and VSTO controls in the Microsoft.Office.Tools.Excel namespace)
I can add a VSTO Smart Tag to a Word Document or Excel Workbook by using an application-level add-in.
The Office 2007 solutions that I compiled with VS 2008 before SP1, continue to function properly when the SP1 update to the VSTO 3.0 Runtime is installed.
I can use the Publish Wizard to successfully create a Click Once deployment for my Office 2007 solution.

By writing our designs in this format, we put ourselves in the place of the customer and create test cases appropriately. We also list the cost of each item in work-days and any risks or dependencies. Then we're able to make informed decisions about which scenarios and how many scenarios we can fix in a given number of work-months. After we've prioritized which features go into the SP, we then write more technical specs that define what is in scope, out of scope, assumptions, UI design diagrams, test specs, security threat models, and lists of dependencies on other teams and the locations of their code drops.

As of today, the VSTO team fixed 143 high severity bugs in the Office features of VS 2008. Five of the fixed bugs were submitted by customers using Connect. I don't have the total bug fix count for the entire division, but it is over a thousand. We are still a few weeks from releasing the Service Pack and we hope to squeeze in a few more critical bug fixes.

We focused on delivering two core scenarios enabling easier deployment and enabling adding Host Controls to application-level add-ins. In the final documentation that will release with SP1, there is a section describing what's new in SP1. Here's the text that you will see in the SP1 documentation after we ship:

What's New in Visual Studio Tools for Office

Visual Studio 2008 Service Pack 1 (SP1) contains updates and new features that affect Visual Studio Tools for Office. The SP1 changes are listed separately from the Visual Studio 2008 features to help you find the latest additions quickly. Visual Studio 2008 SP1 includes features that are designed to help you accomplish the following tasks:
Add Host Controls and Smart Tags to Add-in Projects

You can add smart tags and host controls, such as content controls in Word 2007 and list objects in Excel 2007, to documents in application-level add-in projects. These managed host controls behave like native Office objects, but with added functionality such as events and data-binding capabilities.
To get started, see Adding Controls to Office Documents at Run Time and Smart Tags Overview.
Deploy the Office Primary Interop Assemblies with Your Solution Installer

When you use ClickOnce to deploy solutions for the 2007 Microsoft Office system, the Microsoft Office 2007 Primary Interop Assemblies are automatically selected as prerequisites. The primary interop assemblies are copied to the same deployment folder as your solution installer.
To get started, see How to: Install Prerequisites on End User Computers to Run Office Solutions (2007 System).
Rapidly Deploy Your Solution with the .NET Framework Client Profile

You can now specify the .NET Framework Client Profile as the target Framework version. This smaller version of the .NET Framework decreases the size of your solution during installation by not including all of the Framework assemblies. You can use this with your solutions for the 2007 Microsoft Office system.
To get started, see Creating Office Solutions in Visual Studio.
Troubleshoot Installation with the Event Viewer

· When you install or uninstall Visual Studio Tools for Office solutions, the Visual Studio Tools for Office runtime logs error messages that you can view by using the event viewer in Windows. You can use these messages to help resolve installation and deployment problems.
To get started, see Event Logging (2007 System).

I hope this explanation gives you some insight into the people on my team who build the Office features in Visual Studio and the process we use to prioritize our work.

-Christin Boyd, Program Manager, Microsoft.

-Mary Lee, programming writer, Microsoft.