Before installing Visual Studio 2008 Service Pack 1, you should first uninstall KB944899, a hotfix which improves performance when stepping through source downloaded from a source server.

If KB944899 is not removed prior to Visual Studio 2008 SP1, sometime during the middle of installation an error will occur and the error dialog is displayed as shown below.

Click on the "log file" link in the middle of the dialog. If it opens in Internet Explorer, you may have to click on the yellow information bar that appears on the top to allow scripts to run. Check the "Errors" message type and the following errors are highlighted.

Action: Install patch (C:\Users\heaths\AppData\Local\TEMP\VS90sp1-KB945140-X86-ENU.msp) to Microsoft Visual Studio Team System 2008 Team Suite - ENU
Returning IDOK. INSTALLMESSAGE_ERROR [You must first uninstall the update for KB944899 before this installation can continue]
Patch (C:\Users\heaths\AppData\Local\TEMP\VS90sp1-KB945140-X86-ENU.msp) install failed on product (Microsoft Visual Studio Team System 2008 Team Suite - ENU). Msi Log: Microsoft Visual Studio 2008 SP1 (Beta)_20080516_110428247-MSP0.txt
MsiApplyMultiplePatches returned 0x643

How to workaround this issue

You should remove KB944899 using the following instructions.

Windows Vista and newer

1. Open Control Panel
2. Click on "Programs"
3. Click on "View installed updates"
4. Remove KB944899 listed under any versions of Visual Studio 2008, ex: "Hotfix for Microsoft Visual Studio Team System 2008 Team Suite - ENU (KB944899)"
5. If any other patches are installed on Visual Studio 2008, proceed to "Registry cleanup" below.

Windows XP and Server 2003

1. Open Control Panel
2. Click on "Add / Remove Programs"
3. Check "Show updates"
4. Remove KB944899 listed under any versions of Visual Studio 2008, ex: "Hotfix for Microsoft Visual Studio Team System 2008 Team Suite - ENU (KB944899)"
5. If any other patches are installed on Visual Studio 2008, proceed to "Registry cleanup" below.

Registry cleanup

Newer patches may write the detection data for KB944899 as a mean for detecting hotfixes, so you may need to delete a registry key to prevent VS2008 SP1 from blocking the installation.

1. Open an elevated command prompt
2. Type the following command to determine if any other references to KB944899 are registered
   reg.exe query HKLM\Software\Microsoft\Updates /f KB944899 /k /s
3. For each search result displayed, copy the full key name including spaces and run the following command to delete the key; replace registry key below with the actual registry key included in quotes
   reg.exe delete "registry key" /f

Description of the issue

The original release of KB944899 added new components into existing features which, though documented as supported, forced those features and their feature trees to be installed. If one or more of those features were not installed on a machine, Windows Installer then prompted for source or simply failed during silent installations. Source is required for the files in those features to be installed.

The current download for KB944899 - a new revision - works around this problem and will not block SP1 but many customers already have the original release of KB944899. To prevent prompting for source and installing features not originally selected for installation based on user preference, VS2008 SP1 will block if the original release of KB944899 is installed or appears to be installed.

KB944899 might also appear to be installed because another update might include the same fixes. In this way, older detection code continues to work with the detection keys when a newer update is installed with the same fixes. This is normally beneficial to deployments that require a specific hotfix to be installed even years after the hotfix was released.

One of many improvements made to Visual Studio 2008 Service Pack 1 is that VS 2008 SP1 Beta customers will not need to uninstall SP1 Beta before installing the release of SP1. The same is true for Visual Studio 2008 Express products and .NET 3.5 SP1 - both of which are complete upgrades to older products that may already be on the system or that can be installed on a clean system.

So please read the requirements and known issues, give Visual Studio 2008 SP1 Beta a try, and provide feedback about we can improve the release of VS2008 SP1 and future releases.

Visual Studio 2008 Service Pack 1 is comprised of multiple packages, including executables, installer packages, and patches. Compare this with Visual Studio 2005 SP1 which was a single patch wrapped in an executable. A lot of updates were made to both the .NET Framework and VS 2008 - along with changes to SQL and other bits from across the company - so a download manager was created to download only what you need.

But if you want to put VS 2008 SP1 on your network or a DVD for later or continued use, you can pass /createlayout to the download bootstrap application. The /createlayout parameter requires an argument to specify the directory to download to.

VS90sp1-KB945140-ENU.exe /createlayout \\server\share

After a brief moment, the following dialog is displayed.

This will download all the packages for a single language of VS2008 SP1 and will put an executable named SPInstaller.exe into that same directory. You'll need about 782MB free for SP1 Beta. Run SPInstaller.exe to install the service pack from that install point. SPInstaller.exe will first use valid packages in the same containing folder before fetching them from the Internet.

There is a known issue that .NET Framework 3.5 SP1 requires an active connection when installing the layout. This is because only the web bootstrap application is downloaded. For VS2008 SP1 Beta, you can work around this by downloading the full redistributable and replacing dotnetfx35setup.exe in the layout folder where you saved the rest of the downloaded files. Note that the package you download will be dotnetfx35.exe, so you'll need to rename it to dotnetfx35setup.exe. Just selecting the existing dotnetfx35.exe file in the Save As dialog will do this automatically.

Microsoft Visual Studio 2008 Service Pack 1 (Beta) has been released to web, along with Microsoft .NET Framework 3.5 Service Pack 1 (Beta). Included as part of .NET 3.5 SP1 are Microsoft .NET Framework 2.0 Service Pack 2 (Beta) and Microsoft .NET Framework 3.0 Service Pack 2 (Beta).

Visual Studio 2008 SP1 includes over 250 new features and improvements to existing features, including SQL Server 2008 support. .NET 3.5 SP1 also includes many new features on which VS 2008 SP1 is dependent. Because of this, VS 2008 SP1 chains .NET 3.5 SP1 and other necessary components as you can see from the partial list in the screenshot below.

This means the complete download for VS 2008 SP1 is large - almost twice as large as VS 2005 SP1. The full beta download is about 761 MB which contains the 229 MB full redistributable for .NET 3.5 SP1. However, because of changes we made for VS 2008 SP1 the patch installs in about half of the average time it took for VS 2005 SP1. In addition, we made some additional changes we're sure you'll like.

Smaller Individual Packages

Visual C++ libraries and headers comprised almost 70% of Visual Studio 2005 SP1 and because it was all in a single patch package, everyone had to download it. However, libraries and headers for x64 and IA64 are not installed by default and some customers may not install VC++ at all if they only focus on managed languages such as VB or C#. To save time space, three separate packages are produced for each of x86, x64, and IA64 which contain the libraries and headers for VC++. If you don't have all the VC++ features installed, only part of the overall patch release is downloaded. This does mean, however, that if you later install VC++ features you will need to reinstall SP1 again in order to download and apply the separate patches.

Also by reducing the size of the patch packages, many more customers will be able to install successfully without seeing another 1718 error message stating that the patch was rejected by digital signature policy.

Single Installation Experience

Even though Visual Studio 2008 SP1 includes multiple packages - and not just for Visual Studio - a single user interface using the typical wizard style provides download and installation progress as you see below.

VS2005 SP1 only had a chainer to make sure the patch was correctly applied to each applicable and installed product, but did not implement an external UI handler that provided a consistent and uninterrupted user interface. As a result, some customers canceled dialogs under the assumption that VS2005 SP1 was simply installing again and their machines were not updated fully, sometimes leading to destabilization of Visual Studio 2005.

Friendly Logging

Windows Installer logs are difficult for many to read, so the new external UI chainer generates an HTML log file. Script is embedded in the HTML log to provide filtering mechanisms, but by default the error is displayed. Paths to the MSI logs are also provided in the HTML log to diagnose specific installation problems.

Express SP1 are Major Upgrades

Visual Studio Express products are intended to be downloaded quickly. But VS2005 Express SP1 customers had to download both Express RTM and the appropriate SP1 package that was about the same size resulting in a download and install time of almost twice as long. For VS2008 Express products, customers can simply download Express SP1 whether they have Express RTM installed or not. The product will be upgraded if present in roughly the same amount of time as it takes to install the product fresh. The big advantage for new customers is that they only need to download and install a single package.

Known Issues

For a complete list of known issues, please read the Visual Studio 2008 SP1 Beta Readme.

Silverlight 2 Tools Beta 1 Must be Uninstalled

Before VS2008 SP1 can be installed, Silverlight 2 Tools Beta 1 must be uninstalled. This includes both "Silverlight Tools Beta 1 for Visual Studio 2008" and KB949325. You do not need to remove the Silverlight 2 runtime.

Microsoft .NET Framework 3.5 SP1 Fails to Install

As part of the .NET 3.5 SP1, .NET 2.0 SP2 is installed. A problem occurs on some customers machines due to registry corruption or missing files that prevents 2.0 SP2 from installing which will fail 3.5 SP1. If you run into problems installing 3.5 SP1, please read through KB951950.

Your Machine must be Upgraded Completely

Because a large number of files are shared between products being upgraded, Service Pack 1 must be installed on every applicable product installed on your machine or none of them may work correctly. This means if you have Visual Studio and Express installed, you must download the appropriate updates for each and install them.

Upgrades Must be Uninstalled Individually

For reasons that I'll go into in a future post, we do not provide a uninstall chainer. That is, in order to uninstall SP1 and return your machine back to an RTM state, you must go through Add or Remove Programs and uninstall the service pack components individually. If you have both Visual Studio and Express installed, you may have to uninstall both Express SP1 and Visual Studio and reinstall both at the RTM level again.

Feedback

To provide feedback on the SP1 installation experience or changes to Visual Studio 2008 or Express made by SP1, please visit our forums.

Setup and deployment is a tricky business. Machines can be in many different and often unforeseen states that cause setup to fail. But rarely will setup actually crash, and that is why setup logs are vital to diagnose install, repair, and uninstall problems.

Setup applications for Visual Studio and .NET may write to many different logs because the products are actually comprised of many different packages. Aaron Stebner had documented several log file names for Visual Studio 2008, but with our new and improved patch wrapper we may write even more log files. As we onboard new CTPs for great new features in Visual Studio the list of log files may also grow.

So our QA team has written a tool to collect all these logs for VS 2005 and 2008, and .NET 2.0 through 3.5 aptly named, collect.exe. The link below is an updated version of the old collect.exe that you should use when reporting bugs with setup.

Using the Collect Utility

If you encounter any setup issues, we will need all relevant logs. Please follow the instructions below to collect all those logs.

1. Download collect.exe from the link  below.
2. You may choose to save the tool for later use, or to run directly.
3. The utility creates a compressed cabinet of all the VS and .NET logs to %TEMP%\vslogs.cab.

Reporting Setup Errors

There are several options for reporting setup errors, but you might consider first checking to see if the issue is a known issue. This will save you time and provide more immediate results. In most scenarios, there will be a link on the error page after setup completes. Clicking on this should provide a smaller log that highlights the errors encountered. To dig deeper, check out some of the tips provided on Aaron's blog and on my blog.

If you would like to report an error, be sure to collect logs as described above and choose from the options below.

1. Search or post on MSDN Forums in .NET Framework Setup or Visual Studio Setup and Installation. This is a community-driven web site on which Microsoft employees also participate.
2. Report installation issues or provide feedback for Visual Studio on Microsoft Connect. You may upload logs using Connect. This allows us to view and manage bugs, and customers to vote or provide additional details in a consistent manner.
3. Upload logs using Windows Error Reporting. Both the MSDN Forums and Microsoft Connect will most often provide faster help.

The tool msizap.exe that is available in the Windows SDK and elsewhere on the web (remember to always download from a trusted source) is a powerful but dangerous tool that is often used to quickly and casually, and can leave your machine in a corrupted state if not used correctly. The same is true for the Windows Installer CleanUp Utility which uses msizap.exe.

Windows Installer is a transactional, data-driven deployment technology used by most of the products deployed on Windows platforms today. At its core, it is a loose referential database that describes software applications and that information can be updated by changes, or transforms. That package may describe files, registry values, assemblies, and even custom data that is acted upon by the engine by first generating a script and then executing it. One of the final typical actions of this script is to register product and patch information so that it is cataloged and can be queried; and so that Windows Installer itself can perform future maintenance installations which includes updates and uninstalls.

Updates are supported by actions that first remove older data and then install the newer data. An uninstall essentially skips the install actions. That means, then, that files, registry values, assemblies, and custom data is simply removed.

With that in mind, msizap.exe merely removes the product registration information from the registry and optionally files in the Windows Installer cache - a critical set of files that is necessary for future maintenance installations including proper uninstalls. Removing files from your Windows Installer cache can cause products like the Microsoft .NET Framework 2.0 Service Pack 1 to fail to upgrade older versions.

Msizap.exe is not magic, but merely a tool that acts only on Windows Installer registration data. It will not run the removal actions. So, for example, if you zapped the entire .NET 2.0 RTM products instead of just certain patches, actions that unregister WMI providers incompatible with .NET 2.0 SP1 would not run and, therefore, would not remove the WMI provider registration. In addition, files and other registry data is not removed so the .NET Framework is not truly removed from the system. Msizap.exe is no more of an uninstaller than simply forgetting that a program is installed, which is all it basically causes the Windows Installer engine to do.

Msizap.exe is an effective tool when product registration is already corrupt for whatever reason; however, it should only be used as an absolute last resort. Always try to uninstall a product first through the Add/Remove Programs control panel or the Software Explorer for newer Windows platforms like Vista. If you cannot see the product listed in the control panel, see if there is an "Uninstall" icon or similar in your Start menu for that program group. If you don't see such an item, search the web for what other people have done to uninstall a product. For Windows Installer products, by knowing certain data you can always uninstall from the command line using msiexec.exe. To help diagnose issues properly, always generate a log by passing /L*vx uninstall.log to the command line to msiexec.exe. In this log will almost always be the answer to determine what is wrong so that a product can be properly uninstalled.

For help uninstalling a product when errors are encountered, Aaron Stebner's and my blog can be helpful most often for Visual Studio and .NET installation problems. At times, they may even help in general since problems like registration or cache corruption can happen to any product - especially if msizap.exe was already used improperly. You can also search for error strings you find in the Windows Installer log files which are most often right after the string "Return value 3". The error message number like 1714 you will see is more helpful than a return code at the end of a log like 1603 (0x643).

A lot of customers have recently started seeing the following errors, all stating in various ways that Microsoft .NET Framework 2.0 Service Pack 1 failed to install. You may also see this when attempting to install other updates on top of .NET 2.0 SP1. The error you will see depends on how you are applying updates.

If you are installing .NET 2.0 SP1 or other updates on top of .NET 2.0 RTM by installing the package directly, you may see the following dialog.

If you click on the Error Log hyperlink, the error log simply states the following.

[04/17/08,17:08:27] Microsoft .NET Framework 2.0a: [2] Error: Installation failed for component Microsoft .NET Framework 2.0a. MSI returned error code 1603

If you are attempting to install updates using Windows Update or Microsoft Update, you may see a dialog similar to the following.

If you view the history of the updates you've applied and click on the error icon, the following dialog denotes the same generic error.

To determine the root cause, you need to look in your %TEMP% directory for a file named dd_NET_Framework20_Setup*.txt, where * will be 4 random alphanumeric characters. Find the most recent log if there are multiple logs by sorting by Date Modified.

The problem described here can be found by searching for "Resolving Patch source" in the log file.

How to workaround this issue

If you found the text "Resolving Patch source" in the log file described in the problem description above, you can download the Microsoft .NET Framework 2.0 Registration Correction Tool attached as clwireg.zip and extract the contents. There are three directories corresponding to different computer architectures. Most customers will need to open x86ret and run clwireg.exe. You need to be an administrator to run this utility, and it is only to repair this issue with Microsoft .NET Framework 2.0.

Administrators may also use this utility in scripts by passing either /q or /quiet and it will not display any user interface and will, therefore, not block scripts.

In either case, this tool keeps a running log in %TEMP%\dd_clwireg.txt in which you can read more information about what it has done.

Description of the issue

The specific failure detailed here is caused by corrupted patch registration or a missing patch package.

When Windows Installer performs any maintenance installation - that is any installation after the initial installation, including repairs, patch install and uninstall, and uninstall of the product - it must load the cached installation database and all applicable patches. If those packages are not found in the Windows Installer cache, then Windows Installer attempts to find them previous source directories. Failing to find them, Windows Installer fails the installation with error message 1714, which reads,

Error 1714.The older version of Microsoft .NET Framework 2.0 Service Pack 1 cannot be removed.  Contact your technical support group.  System Error 1612.

System error 1612 is a Windows error code, which identifies the message,

The installation source for this product is not available. Verify that the source exists and that you can access it.

Because .NET 2.0 SP1 is a major upgrade which uninstalls previous versions of .NET 2.0, toward the end of the installation it attempts the uninstall of .NET 2.0 which is a maintenance installation. Because a patch package could not be found, the uninstall attempt fails which causes .NET 2.0 SP1 to rollback and report failure. This may also cause .NET applications to err because of an incomplete rollback.

This problem likely occurs for one of the following two reasons.

The Installer cache is missing the necessary files

The Windows Installer cache located in %WINDIR%\Installer is critical for repairing, updating, and even uninstalling products. It must not be removed, nor any files in it. It is safe - though not advised - to only remove %WINDIR%\Installer\$PatchCache$ or subdirectories if space is critical. This may lead to prompts for source for any products, however, when you attempt to repair or update them.

If this is the case, the line above where you found "Resolving Patch source" would read something similar to the following.

MSI (s) (D0:B0) [19:05:57:843]: Couldn't find local patch 'C:\WINDOWS\Installer\50bad.msp'. Looking for it at its source.
MSI (s) (D0:B0) [19:05:57:843]: Resolving Patch source.

The attached tool attempts to fix this by deleting all patch registration specific to this patch so that future maintenance installations do not attempt to load the patch package.

You may also attempt to fix this by rebuilding the installer cache. You will most often find the KB# for the patch in the lines that follow "Resolving Patch Source", as shown in the following example.

MSI (s) (D0:B0) [19:05:57:859]: SOURCEMGMT: Source is invalid due to missing/inaccessible package.
MSI (s) (D0:B0) [19:05:57:859]: Note: 1: 1706 2: -2147483647 3: NDP20-KB917283-X86.msp

Browse to http://support.microsoft.com and search for the KB# to download the patch again. You can extract the patch using /x or /extract and then following the instructions on rebuilding the installer cache.

Patch registration is corrupt

While we have not yet determined the cause, patch registration may have become corrupted. If this is the case, the line above where you found "Resolving Patch source" would read something similar to the following.

MSI (s) (CC:5C) [03:02:56:181]: Couldn't find local patch ''. Looking for it at its source.
MSI (s) (CC:5C) [03:02:56:181]: Resolving Patch source.

Notice that the location of the patch is missing. In this particular case, a patch is still registered to a product but location information for the patch is missing. The file may or may not exist, but Windows Installer wouldn't even know the path to the file to load.

The attached tool attempts to fix this by deleting all patch registration for this patch so that future maintenance installations do not attempt to load the patch package.

How to prevent this issue

It is critical that you do not remove files located directly in %WINDIR%\Installer, and that you are careful using any disk space reclamation utilities that free up space by deleting large or seldom used files so that you do not allow them to remove these same files. If you have used such a utility that did this, please leave a comment with information about that tool and we'll work with developers to try to mitigate this problem in the future.

The Windows Installer CleanUp Utility which uses msizap.exe (also shipped with the Windows SDK) is capable of deleting some or all files in the Installer cache but should be used only as a last resort and after carefully reading all information and warnings about the tool. It is always best to uninstall a product or patch correctly using Windows Installer either through Add/Remove Programs on Windows 2000, XP, or Server 2003; Software Explorer on Vista and newer; or using msiexec.exe on the command line if the product does not provide its own uninstaller.

Updated: the issue and workaround have been adapted for KB951950 and I have updated the attachment to refer to the Microsoft Download Center location.

While developing unit and functional tests for Windows Installer PowerShell Extensions, I needed a way to invoke cmdlets without requiring elevation on Vista. That is, of course, because running elevated has always been a bad idea unless it is required. In order to load a PowerShell snap-in, however, one must write to HKEY_LOCAL_MACHINE which requires elevated privileges. Other than that, there really isn't another reason to run elevated.

Fortunately, PowerShell allows developers to define a RunspaceConfiguration object which, among other properties, allows developers to add specific types as cmdlets. Without being defined by a registered snap-in, cmdlets can then be invoked in a Runspace as shown below in a sample Visual Studio test class.

using System;
using System.Management.Automation;
using System.Management.Automation.Runspaces;
using Microsoft.Windows.Installer.PowerShell.Commands;
using Microsoft.VisualStudio.TestTools.UnitTesting;

[TestClass]
public class GetFileHashCommandTest
{
    private RunspaceConfiguration config;

    [TestInitialize]
    public void Initialize()
    {
        config = RunspaceConfiguration.Create();
        config.Cmdlets.Append(new CmdletConfigurationEntry(
            "Get-MSIFileHash",
            typeof(GetFileHashCommand),
            "Microsoft.Windows.Installer.PowerShell.dll-Help.xml"));
    }

    [TestMethod]
    [DeploymentItem(@"data\example.txt")]
    public void PathTest()
    {
        using (Runspace rs = RunspaceFactory.CreateRunspace(config))
        {
            rs.Open();
            using (Pipeline p = rs.CreatePipeline(@"get-msifilehash -path example.txt"))
            {
                Collection<PSObject> objs = p.Invoke();
                Assert.AreEqual<int>(1, objs.Count);
            }
        }
    }
}

When it is time to install and register your PowerShell snap-in, I recommend you take a look at the WiX PowerShell extension to avoid using managed custom actions which can also cause problems.

The Windows Installer team released Windows Installer 4.5 Beta 2 recently. While not a lot has visibly changed since the first beta for which I provided an overview, it's important to note that a new column was added to the CustomAction table since changes to column types are not supported in a transform or patch but adding a new column is supported.

The ExtendedType column is defined as a nullable DoubleInteger, or I4 using IDT format codes. Currently the only supported value is the new msidbCustomActionTypePatchUninstall (0x8000) that denotes a patch uninstall custom action, which is the feature to deploy a custom action in a patch that will execute when that patch is uninstalled. This was previously impossible without hooks in a baseline product because a patch is uninstalled by removing the patch from the aggregate view of the product and all applicable updates, and then repairing the product.

For more information and to sign up for the Windows Installer 4.5 pre-release program, visit Windows Installer 4.5 on Microsoft Connect.

For my Windows Installer PowerShell Extensions, I've been simplifying some of the use cases and adding additional formats. One thing I wanted to do was display source list information in a table and group either by the attached ProductCode or PatchCode properties. The format-table cmdlet doesn't support multiple properties and doesn't appear to allow you to condition the label. It also seemed that Display.xml, or *.formats.ps1xml files, didn't natively support grouping by multiple property names.

The help topic about_Display.xml hinted at a CustomControl tag, but examples of this and related tags in the default *.formats.ps1xml files offered little insight about their true power. With some help from a simple user-generated XML schema and some trial and error, I was able to display a label with an appropriate value conditionally, such that the following expressions displayed the partial table shown below.

PS> $packages = get-msiproductinfo | ?{ $_.Name -match "Visual Studio" }
PS> $packages += get-msipatchinfo
PS> $packages | get-msisource | format-table -view package

    ProductCode: {388E4B09-3E71-4649-8921-F44A3A2954A7}

Index Type    Path
----- ----    ----
    0 Network m:\c0367ae0d89851da1a\
    1 Network C:\Program Files\Common Files\Microsoft Shared\VSTO\8.0\Micros...
    2 Network m:\3d218a0f32f61beaf41a01459217\

    PatchCode: {6E52C409-0D0D-4B84-AB63-463438D4D33B}

Index Type    Path
----- ----    ----
    0 Network m:\ec91ccc92c8f730e8d87188036\

I accomplished this by using a scriptblock to group, but referencing a CustomControl with multiple ExpressionBinding elements as shown in the partial example below.

<Configuration>
  <Controls>
    <Control>
      <Name>PatchOrProductGrouping</Name>
      <CustomControl>
        <CustomEntries>
          <CustomEntry>
            <CustomItem>
              <Frame>
                <LeftIndent>4</LeftIndent>
                <CustomItem>
                  <ExpressionBinding>
                    <ItemSelectionCondition>
                      <ScriptBlock><![CDATA[$_.ProductCode -ne $null]]></ScriptBlock>
                    </ItemSelectionCondition>
                    <ScriptBlock><![CDATA["ProductCode: " + $_.ProductCode]]></ScriptBlock>
                  </ExpressionBinding>
                  <ExpressionBinding>
                    <ItemSelectionCondition>
                      <ScriptBlock><![CDATA[$_.PatchCode -ne $null]]></ScriptBlock>
                    </ItemSelectionCondition>
                    <ScriptBlock><![CDATA["PatchCode: " + $_.PatchCode]]></ScriptBlock>
                  </ExpressionBinding>
                  <NewLine/>
                </CustomItem>
              </Frame>
            </CustomItem>
          </CustomEntry>
        </CustomEntries>
      </CustomControl>
    </Control>
  </Controls>
  <ViewDefinitions>
    <View>
      <Name>Package</Name>
      <ViewSelectedBy>
        <TypeName>Microsoft.Windows.Installer.PackageSource</TypeName>
      </ViewSelectedBy>
      <GroupBy>
        <ScriptBlock><![CDATA[
          if ($_.ProductCode -ne $null)
          {
            $_.ProductCode
          }
          elseif ($_.PatchCode -ne $null)
          {
            $_.PatchCode
          }
        ]]></ScriptBlock>
        <CustomControlName>PatchOrProductGrouping</CustomControlName>
      </GroupBy>
      <TableControl>
        <!-- Omitted for brevity -->
      </TableControl>
    </View>
  </ViewDefinitions>
</Configuration>