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.