Recently, I needed to configure and use a virtual server image that was provided to me by another team here at Microsoft.  In order to do this, I had to install and configure Virtual Server 2005 to host this image on my desktop OS.  I am running Windows Vista Ultimate edition on this system, and I found that I had to perform a few configuration steps in order to get Virtual Server 2005 to install and run correctly on Windows Vista.  I found these steps through various conversations and web searches, so I decided to consolidate them in one place in case anyone runs into similar issues in the future (and to make sure I could find them and replicate them again myself if I need to....)

Here are the steps I had to take on my Windows Vista Ultimate system in order to install, configure and use Virtual Server 2005:

Add IIS features on an existing Windows Vista OS

IIS is not installed by default when installing Windows Vista, so in most cases you will need to add several IIS features before being able to install Virtual Server 2005 on Windows Vista.   I used the following steps to add IIS to my Windows Vista system that is running the Ultimate edition:

1. Go to the Programs and Features control panel.  I typically do this by pressing the Windows key + R and typing appwiz.cpl in the run dialog
2. Click the Turn Windows features on or off link in the Tasks list on the left side of the Programs and Features control panel, and click Continue to launch with administrator privileges
3. In the Windows Features dialog, locate the item named Internet Information Services in the feature tree.  Check the root node to enable the default set of IIS features
4. Expand the root node and check the following child nodes that do not end up getting checked by default (this is the list of items that I checked, but I don't know for sure if all of them are necessary in order to use Virtual Server 2005):  all of the IIS 6 management tools under the Web Management Tools node, all of the features in the Application Development Features, Common Http Features and Security nodes under the World Wide Web Services node
5. Click OK to add all of the IIS features that you selected in the previous 2 steps
6. Reboot after IIS feature installation completes

Install Virtual Server 2005

Once you have added the appropriate IIS features on your Windows Vista system, you can proceed to install Virtual Server 2005.  You should see a UI page during Virtual Server 2005 setup that allows you to configure the Virtual Server web site.  If you have not properly configured IIS, you will likely see an error message during this phase of Virtual Server setup.  If that is the case on your system, you should reboot and then return to the Windows Features control panel and verify the installation state of the IIS components on your system.

Add an IIS handler mapping so it will treat EXE files as CGI

After adding IIS features to your Windows Vista system and installing Virtual Server 2005, you will need to configure a new handler mapping for the VirtualServer web site.  To do this, I used the following steps (there may be other ways of doing this, but this is the way I found that worked for me):

1. Go to the Windows start menu, choose All Programs, then Administrative Tools, then Internet Information Services (IIS) Manager
2. Click Continue to launch the IIS Manager application with administrator privileges
3. In the Connections tree control on the left side of the IIS Manager UI, expand Web Sites, then expand Default Web Site, find the VirtualServer web site and click on it
4. In the main pane, you should see /VirtualServer Home.  Select Group by area if it is not currently selected in the Group by drop down.  Then find the IIS settings section and double-click on the item named Handler Mappings
5. In the Handler Mappings pane, right-click and select Add Module Mapping...
6. In the Request path text box, enter *.exe
7. In the Module drop-down, select CgiModule.  If you do not see CgiModule listed in this drop-down, you will need to go back to the control panel and make sure that you add the CGI feature to IIS (located under Internet Information Services | World Wide Web Services | Application Development Features | CGI in the Windows Features control panel), then try these steps again
8. In the Name text box, provide a friendly name for the module mapping.  I used EXE-to-CGI, but it doesn't matter what you type here
9. Click OK to add the module mapping to the VirtualServer web site
10. In the Connections tree control on the left side of the IIS Manager UI, expand Web Sites, then right-click on the Default Web Site and choose Restart to make sure that the changes made above will take effect

Create a shortcut to launch the Virtual Server administration Web site as an administrator

In order to be able to launch the Virtual Server administration Web site on Windows Vista, you have to start Internet Explorer 7 with administrator privileges.  It is possible to manually launch IE7 by right-clicking on it and choosing Run as administrator, then manually navigate to the Virtual Server administrator site.  However, that can get annoying if you find yourself needing to open this site frequently.  Fortunately, I found this blog post that describes how to create a shortcut that will automatically launch IE7 with elevated privileges and navigate to the Virtuan Server administration Web site after you grant it permission to launch.  To summarize those steps, you will need to do the following:

1. Right-click on your Windows Vista desktop and choose New, then Shortcut
2. In the Create Shortcut dialog, copy and paste the following into the text box for the location of the item (this assumes you have Windows Vista installed to the default location on the C drive, so you will need to adjust this path as appropriate if that is not the case on your system):
   
   "C:\Program Files\Internet Explorer\iexplore.exe" http://localhost/VirtualServer/vswebapp.exe?view=1
   
3. Click Next, then provide a friendly name for the shortcut such as Virtual Server administration site
4. Click Finish to create the shortcut on your desktop
5. Find the newly created shortcut, right-click on it and choose Properties
6. Click the Advanced button in the Properties dialog
7. Check the box labeled Run as administrator and click OK
8. Move the shortcut to whatever location you prefer (the Windows start menu, the Quick Launch bar, etc)

<update date="10/31/2007"> Added steps to the shortcut creation instructions that I missed initially to cause the shortcut to prompt for elevation every time it is double-clicked </update>

I ran across a few interesting posts on the Application Consulting and Engineering (ACE) team's blog that I wanted to link to here so that more folks will hopefully see them.  The ACE team announced a public beta this past week for a tool created by their team named XSSDetect.  This tool is a Visual Studio plug-in that does static code analysis to detect potential cross-site scripting (XSS) issues in web applications.

Here are some useful links about the XSSDetect tool and cross-site scripting:

• Blog post announcing the XSSDetect beta - http://blogs.msdn.com/ace_team/archive/2007/10/22/xssdetect-public-beta-now-available.aspx
• XSSDetect beta download location - http://www.microsoft.com/downloads/details.aspx?FamilyID=19a9e348-bdb9-45b3-a1b7-44ccdcb7cfbe&displaylang=en
• Details about how XSSDetect does dataflow analysis - http://blogs.msdn.com/hackers/archive/2007/10/23/some-technical-details-on-how-xssdetect-does-dataflow-analysis.aspx
• Using XSSDetect to analyze large applications - http://blogs.msdn.com/ace_team/archive/2007/10/24/xssdetect-analyzing-large-applications.aspx
• MSDN topic about the anti-cross site scripting library - http://msdn2.microsoft.com/en-us/security/aa973814.aspx

If you are building or testing web applications, I encourage you to check out the XSSDetect tool and the information in the above links to see if it might be useful in your development and testing processes.

My new team is using WiX v3.0 to create the MSI-based setups for the upcoming XNA Game Studio 2.0 product.  One of the readiness activities we're working on prior to shipping is testing the process of building and installing patches for these MSIs.

Our primary setup developer started out with this testing process by investigating the patching features in WiX v3.0.  She read through the introductory information in Peter Marcu's blog.  In particular, she attempted to use the sample patch build instructions in this blog post to create an MSP for one of our MSIs.  While doing this, she found that our build process was not creating or archiving .wixout files, which are required to build patches using these instructions.

Fortunately, a couple of things have changed in WiX v3.0 since the time that Peter wrote that blog post.  The first was a code change that Peter added in early August to WiX v3.0 that makes the WiX build process produce artifacts needed for patching by default.  In other words, you have to pass command line switches to turn off the creation of the files instead of to turn it on, which means that if you don't know about the need to create these artifacts at the time that you build your original product, you won't have to go back and rebuild your baseline product before you can build an upgrade layout and a patch.  You can see this change in recent WiX v3.0 builds (3.0.3210.0 or higher) by performing a default compile and link and observing the .wixpdb files that are created.  You can also see the -spdb switch that is now available in light.exe to suppress the creation of the .wixpdb files.

The second change in WiX 3.0 is some greatly enhanced patch building documentation that was added to wix.chm by Heath Stewart (he references these docs in this blog post).  If you have a recent build of WiX v3.0 (build 3.0.3210.0 or higher), you can see the new patching documentation in wix.chm by looking under WiX Help | Authoring | Patch Building in the table of contents.

Since the contents of wix.chm are not searchable via Web search engines, I am going to transcribe an updated set of instructions from one of the help topics that Heath wrote so that people using more recent builds of WiX v3.0 will hopefully find and use these instructions instead of the ones that Peter originally posted when getting started building patches using WiX v3.0.

Patch Building Using Purely WiX

A patch can now be created purely in WiX using new tools, Torch.exe and Pyro.exe. This also eliminates the need to perform administrative installs or even bind the upgrade product which, for large products, can be exhaustive.  Creating a patch consists of 3 steps:

• Setting up the patch sample
• Building the patch sample
• Verify the patch sample

Setting Up the Patch Sample

A sample product is created which puts different resources into fragments. The purpose of putting resources into separate fragments is so that the resources in each fragment can be filtered out of a patch. You might filter some resources out of a patch if you only want to limit the patch to update only parts of your product or products.

1.  Create a directory that will contain the sample

Create a directory from which you plan on running the sample. This will be the sample root.

md C:\sample

2.  Create two subdirectories

Under the sample root create two subdirectories called "1.0" and "1.1".

md C:\sample\1.0
md C:\sample\1.1

3.  Create a text file called Sample.txt for 1.0

Create a text file in the "1.0" directory called Sample.txt and put some text in it telling you that it is the 1.0 version of the file.

echo This is version 1.0 > C:\sample\1.0\Sample.txt

4.  Create a text file called Sample.txt for 1.1

Create a text file in the "1.1" directory called Sample.txt and put some text in it telling you that it is the 1.1 version of the file.

echo This is version 1.1 > C:\sample\1.1\Sample.txt

5.  Create your product authoring in the sample root folder

Create your product authoring in the sample root folder called Product.wxs with the following contents:

<?xml version="1.0" encoding="UTF-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
    <Product Id="48C49ACE-90CF-4161-9C6E-9162115A54DD"
        Name="WiX Patch Example Product"
        Language="1033"
        Version="1.0.0"
        Manufacturer="Dynamo Corporation"
        UpgradeCode="48C49ACE-90CF-4161-9C6E-9162115A54DD">
        <Package Description="Installs a file that will be patched."
            Comments="This Product does not install any executables"
            InstallerVersion="200"
            Compressed="yes" />
        <Media Id="1" Cabinet="product.cab" EmbedCab="yes" />
        <FeatureRef Id="SampleProductFeature"/>
    </Product>
    <Fragment>
        <Feature Id="SampleProductFeature" Title="Sample Product Feature" Level="1">
            <ComponentRef Id="SampleComponent" />
        </Feature>
    </Fragment>
    <Fragment>
        <DirectoryRef Id="SampleProductFolder">
            <Component Id="SampleComponent" Guid="{C28843DA-EF08-41CC-BA75-D2B99D8A1983}" DiskId="1">
                <File Id="SampleFile" Name="Sample.txt" Source=".\$(var.Version)\Sample.txt" />
            </Component>
        </DirectoryRef>
    </Fragment>
    <Fragment>
        <Directory Id="TARGETDIR" Name="SourceDir">
            <Directory Id="ProgramFilesFolder" Name="PFiles">
                <Directory Id="SampleProductFolder" Name="Patch Sample Directory">
                </Directory>
            </Directory>
        </Directory>
    </Fragment>
</Wix>

6.  Create your patch authoring in the sample root

Create your patch authoring in the sample root called Patch.wxs with the following content:

<?xml version="1.0" encoding="UTF-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
    <Patch
        AllowRemoval="yes"
        Manufacturer="Dynamo Corp"
        MoreInfoURL="http://www.dynamocorp.com/"
        DisplayName="Sample Patch"
        Description="Small Update Patch"
        Classification="Update"
        >
        <Media Id="5000" Cabinet="RTM.cab">
            <PatchBaseline Id="RTM"/>
        </Media>
        <PatchFamilyRef Id="SamplePatchFamily"/>
    </Patch>
    <Fragment>   
        <PatchFamily Id='SamplePatchFamily' Version='1.0.0.0' Supersede='yes'>
            <ComponentRef Id="SampleComponent"/>
        </PatchFamily>
    </Fragment>
</Wix>

Building the Patch Sample

Open a command prompt and make sure that the following WiX tools are in your PATH.

• Candle.exe
• Light.exe
• Torch.exe
• Pyro.exe

Your WiX toolset version should be at least 3.0.3210.0

1.  Build the target layout

While only the wixpdb is needed, the target product layout is created to test installing the patch which requires the product is also installed before or along with the patch.

cd C:\sample
candle.exe -dVersion=1.0 product.wxs
light.exe product.wixobj -out 1.0\product.msi

2.  Build the upgrade layout

candle.exe -dVersion=1.1 product.wxs
light.exe product.wixobj -out 1.1\product.msi

3.  Create the transform between your products

torch.exe -p -xi 1.0\product.wixpdb 1.1\product.wixpdb -out patch\diff.wixmst

4.  Build the patch

The patch.wxs file is compiled and linked similar to a product, but then processed along with any number of transforms that you want contained in the patch. That produces an MSP file that targets any of the products from which transforms were created that contain at least some small change after filtering.

candle.exe patch.wxs
light.exe patch.wixobj -out patch\patch.wixmsp
pyro.exe patch\patch.wixmsp -out patch\patch.msp -t RTM patch\diff.wixmst

Verify the Patch

To verify that the patch works, install the product and then the patch.

1.  Install the 1.0 product

msiexec.exe /i 1.0\product.msi /l*vx install.log

2.  Verify version 1.0

Go to "Program Files\Patch Sample Directory" and open Sample.txt. Verify that this is the 1.0 version. Close Sample.txt.

3.  Install the patch

msiexec.exe /p patch\patch.msp /l*vx patch.log

4.  Verify version 1.1

Go to "Program Files\Patch Sample Directory" and open Sample.txt. Verify that this is now the 1.1 version. Close Sample.txt.

5.  Uninstall the patch

On Windows XP Service Pack 2 and Windows Server 2003, go to "Add/Remove Programs" in the Control Panel and make sure that Show Updates is checked. On Windows Vista and newer, go to "Programs" then "View installed updates" in the Control panel. Select "Sample Patch" from under "WiX Patch Example Product" and click the Uninstall button.

Go to "Program files\Patch Sample Directory" and open Sample.txt. Verify that this is again the 1.0 version. Close Sample.txt.

6.  Uninstall the product

On Windows XP Service Pack 2 and Windows Server 2003, go to "Add/Remove Programs" in the Control Panel. On Windows Vista and newer, go to "Programs" then "Uninstall a program" in the Control Panel. Select "WiX Patch Example Product" and click the Uninstall button.

Restrictions

In addition to restrictions about what can be in a patch for it to correctly install and uninstall, building patches using purely WiX has additional restrictions to help ensure that your patch works correctly.

1.  Patch families can only ever grow

Patch families are used to filter resources that should end up in a patch. Once the patch is created, these patch families dictate which patches are superseded. If a resource is removed from a patch family in a newer patch when that resource is contained in an older patch with the same patch family, when the older patch is superseded that resource will be regressed back to its previous state before the older patch was even installed.

Note that in order for one patch to supersede any other patches, all patch families must be superseded. A single patch family is referenced in the example above for simplicity.

2.  Certain elements cannot be added to uninstallable patches

There are certain elements referenced in restrictions that cannot be added or modified if the patch is to be uninstallable. If a Patch/@AllowRemoval is set to "yes" and any of these elements are added or modified, Pyro.exe will return an error. These elements compile into tables that Windows Installer restricts in patches, so WiX informs and prevents you from creating an uninstallable patch that you want to be uninstallable.

Question:

I would like to try to automate the instructions for removing and reinstalling the .NET Framework that are described in this blog post.  I saw your previous blog post about running the .NET Framework cleanup tool in silent mode.  Are there also command line switches that I can use to run the .NET Framework setup verification tool in silent mode?

Answer:

Yes, it is possible to run the .NET Framework setup verification tool in silent mode.  To do that, you need to download the .NET Framework setup verification tool, extract the file SetupVerifier_NetfxAll.exe from the zip file, and run it using syntax like the following:

setupverifier_netfxall.exe /q:a /c:"vsverify.exe /q /p <name of product to verify> /l <language of product to verify>"

The values that you pass with the /p switch to replace <name of product to verify> and the /l switch to replace <language of product to verify> in this example must exactly match a product name and language listed in the file vsverify.ini that is included in the self-extracting package for the setup verification tool.

For example, if you would like to run the .NET Framework setup verification tool to silently verify the setup for the .NET Framework v2.0 (x86):

setupverifier_netfxall.exe /q:a /c:"vsverify.exe /q /p .NET Framework v2.0 (x86) /l All"

The .NET Framework setup verification tool returns 0 if verification is successful and non-zero if there are errors.

There is a file named setupverifier_readme.txt included in the .NET Framework setup verification tool zip file that explains in more detail how the setup verifier works and how to run it in silent mode.  The readme includes a complete list of supported product name and language values that can be passed in via the /p and /l command line switches when running the tool in silent mode.

I have gotten several questions from customers about how to resolve installation problems with the .NET Framework 3.0 since it was released last year.  In many of these cases, the installation problems and options for workarounds were described in the .NET Framework 3.0 release notes.  However, it looks like some of my blog posts appear earlier in the list of Web search results than these release notes, and in some sample searches that I tried, the release notes do not appear at all.

In an effort to try to improve the discoverability of the setup issues and workarounds listed in the .NET Framework 3.0 release notes, I wanted to provide a link to the release notes on my blog and also summarize some of the issues that are listed in the release notes.

You can find the .NET Framework 3.0 release notes at http://msdn2.microsoft.com/windowsvista/bb188202.aspx.

These release notes include information about the following types of .NET Framework 3.0 setup issues:

• How to troubleshoot download errors
• Possible issues that can arise when installing the .NET Framework 3.0 on a system that previously had a beta version of WinFX or the .NET Framework 3.0 installed
• Install failures related to IIS metabase corruption (this is listed as a beta upgrade issue, but I have heard of this type of issue very often and it can happen both on systems that previously had a 3.0 beta and systems that have never had 3.0)

If you are encountering errors while trying to install the .NET Framework 3.0, I encourage you to take a look at these release notes to see if you are experiencing any of the known issues documented there.  If those workarounds do not help, you can search in the .NET Framework 3.0 setup log files for additional information about the root cause of the failure.  A complete list of .NET Framework 3.0 setup log files is located at http://blogs.msdn.com/astebner/archive/2006/10/30/net-framework-3-0-setup-log-files.aspx.

One final note here - the .NET Framework 3.5 installer includes the .NET Framework 3.0 with SP1 as a prerequisite.  If you encounter failures during .NET Framework 3.5 setup during the installation of this 3.0 SP1 prerequisite package, the information in the .NET Framework 3.0 release notes may be helpful to you as well.

A new portal with information about software testing has been posted this week on MSDN.  You can check it out at http://msdn2.microsoft.com/testing/default.aspx.  To summarize the launch note on this page:

At the Tester Center, our goal is to provide a community where software testers can share knowledge and learn from each other about testing, our day-to-day job functions, processes, the tools we use, and the various roles we play.

The Tester Center contains links to videos, articles, testing guidelines and best practices, blogs and other useful information.  In addition, there is a software testing discussion forum available at http://forums.microsoft.com/msdn/showforum.aspx?forumid=1600&siteid=1.

I encourage you to take a look at the Tester Center if you work in a software development or testing field for some useful resources to hopefully help you produce higher quality code throughout the development cycle.

Robert Flaming has posted a helpful analysis of the issues that need to be considered when using EXEs in Windows Installer custom actions.  You can find this analysis at http://blogs.msdn.com/windows_installer_team/archive/2007/10/20/integration-hurdles-for-exe-custom-actions.aspx.

If you are working on a Windows Installer-based setup and are considering whether to write an EXE or a DLL for a custom action in your package, I encourage you to review this list of issues and test scenarios to familiarize yourself with some of the issues that can affect EXE custom actions.

I have seen questions pop up fairly frequently both on internal Microsoft mailing lists and on the WiX mailing lists on SourceForge about how to use the built-in custom actions included in extension DLLs in WiX v3.0.

This is one of the big changes that folks notice when they migrate any existing setup authoring from WiX v2.0 to WiX v3.0.  The built-in custom actions used to ship in libraries like wixca.wixlib, wixui.wixlib, sca.wixlib, etc in WiX v2.0, but those files are no longer shipped directly as a part of WiX v3.0.  Instead, they are embedded into extension DLLs.  The extension DLLs in WiX v3.0 include such things as the WixUI dialog library, the IIS custom actions, server custom actions, system information custom actions, etc.

I pulled together some answers to this type of question from Justin Rockwood and a couple of other folks and created a new topic in the v3.0 wix.chm file (starting in build 3.0.3419.0) that introduces how to use extensions in your WiX 3.0 authoring and build process.  Justin had a great idea to post this topic on his blog, and so I figured I'd post it on mine as well in order to help improve discoverability via search engines, etc.

Using extensions when calling WiX tools via the command line

To use a WiX v3.0 extension when calling the WiX tools directly, you need to use the -ext command line parameter available in the Candle, Light and Lit tools and pass in the extension DLL(s) needed for your project.  Each extension DLL must be passed in via separate -ext parameters.  For example:

light.exe MySetup.wixobj -ext "c:\Program Files\Windows Installer XML v3\bin\WixUIExtension.dll" -ext "c:\Program Files\Windows Installer XML v3\bin\WixUtilExtension.dll" -out MySetup.msi

Using extensions when building an MSI in Votive

To use a WiX v3.0 extension when building in Visual Studio with the Votive add-in, you can use the following steps:

1. Right-click on the WiX project in the Visual Studio solution explorer and select Add Reference...
2. In the Add WiX Library Reference dialog, click on the Browse tab and browse to the WiX extension DLL that you want to include.
3. Click the Add button to add a reference to the chosen extension DLL.
4. Browse and add other extension DLLs as needed.

After you have added a reference to an extension DLL, Votive will automatically add the appropriate -ext command line switches when it calls Candle, Light and/or Lit.

Enabling IntelliSense for extensions in the VS IDE

To enable IntelliSense for a WiX extension in the Visual Studio IDE, you must also add an XMLNS declaration to the <Wix> element in your WXS file.  For example, if you want to use the NativeImage functionality in the WixNetFxExtension, you can use a <Wix> element that looks like the following:

<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi"
        xmlns:netfx="http://schemas.microsoft.com/wix/NetFxExtension">

After adding this, you can add an element named <netfx:NativeImage/> and view IntelliSense for the attributes supported by the NativeImage element.

I previously posted a list of registry values that can be used to detect Visual Studio 2005 editions.  I've started getting asked more often about how to detect Visual Studio 2008, so I decided to create a separate post with an equivalent list of registry values for the VS 2008 product family too.

Here is a list of the registry keys/values that can be used to detect each of the editions of Visual Studio 2008.  In each case below, ProductDir is a REG_SZ value that contains the install root (which by default will be c:\Program Files\Microsoft Visual Studio 9.0).

• Visual Basic 2008 Express - HKEY_LOCAL_MACHINE\Software\Microsoft\VBExpress\9.0\Setup\VS\ProductDir
• Visual C++ 2008 Express - HKEY_LOCAL_MACHINE\Software\Microsoft\VCExpress\9.0\Setup\VS\ProductDir
• Visual C# 2008 Express - HKEY_LOCAL_MACHINE\Software\Microsoft\VCSExpress\9.0\Setup\VS\ProductDir
• Visual WebDev 2008 Express - HKEY_LOCAL_MACHINE\Software\Microsoft\VWDExpress\9.0\Setup\VS\ProductDir
• Visual Studio 2008 Standard - HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\9.0\Setup\VS\Std\ProductDir
• Visual Studio 2008 Professional - HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\9.0\Setup\VS\Pro\ProductDir
• Visual Studio Team System 2008 Architecture Edition - HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\9.0\Setup\VS\VSTA\ProductDir
• Visual Studio Team System 2008 Test Edition - HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\9.0\Setup\VS\VSTT\ProductDir
• Visual Studio Team System 2008 Development Edition - HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\9.0\Setup\VS\VSTD\ProductDir
• Visual Studio Team System 2008 Team Suite - HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\9.0\Setup\VS\VSTS\ProductDir
• Visual Studio 2008 Shell - HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\9.0\Setup\VS\IDE\ProductDir

If you do not care which edition is installed, you can use the following registry value to detect whether or not any edition of Visual Studio 2008 is installed:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\SxS\VS7\9.0

9.0 is a REG_SZ value that specifies a fully qualified path to the Visual Studio 2008 root installation directory.  By default, this value will be set to c:\Program Files\Microsoft Visual Studio 9.0, but will be different if the user has installed Visual Studio 2008 to a non-default path.

Over the past couple of weeks, I've heard from a few users who tried to run the .NET Framework cleanup tool on Windows 2000 but were unable to.  On these systems, users received errors stating that the program named cleanup_tool.exe could not be run because it is not a valid Win32 application.  This issue was tricky to narrow down, so I wanted to describe the underlying issue in case it helps anyone else who runs into similar issues in the future.

I only started hearing about this issue recently, and I could not reproduce it on my Windows XP, Windows Server 2003 or Windows Vista systems.  So I tried to narrow down the root cause by looking more closely at the recent changes that I made to the cleanup tool.

The one major change that I made over the past month or so was to update the build script for the tool to embed a UAC manifest using the tool mt.exe as described in this MSDN topic.  I did this to cause the cleanup tool to prompt for elevation when it is run on Windows Vista.

The UAC manifest contains settings that did not exist at the time that Windows 2000 shipped, but Windows will ignore manifest settings that it does not recognize.  In addition, I built a version of the cleanup tool without an embedded manifest and sent it to one of the customers, and they indicated that it did not help resolve this invalid Win32 application error.  This meant that the addition of the UAC manifest was not the root cause of this error on Windows 2000.

The only other thing changed recently was that I started building the cleanup tool on a Windows Vista system instead of a Windows Server 2003 system.  Since I didn't have any other changes that could explain this error, I started examining this change in more detail.

I use the IExpress technology to create the self-extracting package for the cleanup tool.  A version of IExpress.exe is installed to %windir%\system32 on all recent versions of Windows, and the cleanup tool build script uses this version of IExpress.exe that comes with the OS.

After discussing this issue with a couple of folks who have debugged similar issues in the past, I used the tool dumpbin.exe that is a part of Visual Studio to compare the portable executable (PE) header information for an older version of the cleanup tool that worked correctly on Windows 2000 and the newest version of the cleanup tool that was not recognized as a valid Win32 application on Windows 2000.  When I did that, I found that the working version of cleanup_tool.exe had the following attributes:

• Operating system version – 5.02
• Image version – 5.02
• Subsystem version – 4.00

The broken version of cleanup_tool.exe had the following attributes:

• Operating system version – 6.00
• Image version – 6.00
• Subsystem version – 5.01

It turns out that Windows 2000 only recognizes EXEs that have subsystem versions less than or equal to 5.00.  I also found out during this investigation that the Windows Vista version of IExpress.exe embeds a subsystem version of 5.01 in the self-extracting EXEs it creates.  In previous versions of Windows, IExpress.exe embeds a subsystem version of 4.00 in the self-extracting EXEs it creates.

After I discovered this, I built an updated version of the cleanup tool using a Windows Server 2003 version of IExpress.exe and had a couple of customers try it on their Windows 2000 systems and the tool extracted and ran as expected.

If you run into any issues where Windows reports that an EXE is not a valid Win32 application, I suggest taking a look at the PE header information for the EXE by using the dumpbin.exe tool to see if you are running into a similar issue to the one I ran into with the .NET Framework cleanup tool.

The version of the cleanup tool located at http://astebner.sts.winisp.net/Tools/dotnetfx_cleanup_tool.zip contains the correct PE header information to allow it to run correctly on Windows 2000 again.  Thank you to the folks who reported this issue to me and helped me test out possible fixes.

Recently, a fellow Microsoft employee found this blog post that I wrote a while back, and he contacted me with a question regarding some odd behavior he was seeing with the Program Compatibility Assistant (PCA) on Windows Vista.  He found that a specific EXE consistently triggered a PCA dialog when he closed it on his system, but nobody else on his team saw this behavior for this EXE on their systems.  What made this even more strange was that this EXE included an embedded UAC manifest, which should prevent Windows Vista from triggering any PCA dialogs for the EXE.

After consulting with the Windows application compatibility team, we finally found the root cause and were able to fix this system so it no longer triggers PCA dialogs for this EXE.  In the process, we learned some interesting details about how Windows Vista works behind the scenes when deciding whether or not to trigger a PCA dialog.  I haven't seen this information documented very thoroughly so far, so I wanted to post about this experience here in case it is helpful to anyone else.

Problem 1 - The embedded UAC manifest was not recognized

The EXE in question had an embedded UAC manifest, but it was embedded using resource ID value 0.  Once the EXE was rebuilt with the UAC manifest embedded using resource ID value 1, then Windows Vista was able to find the manifest, and it stopped triggering PCA dialogs on this system.

For reference, the instructions in this MSDN topic can be used to embed a UAC manifest in an EXE using Visual Studio or via command line using mt.exe from the Windows SDK.  The examples in this topic demonstrate how to embed the manifest using resource ID value 1, but the topic does not specifically state that you have to use resource ID value 1.  The experience we had debugging this issue suggests otherwise.

Problem 2 - Windows Vista logic for triggering PCA was affected by an uninstalled application

Due to the unrecognized UAC manifest described in problem 1, this EXE was treated by Windows Vista as a legacy application, which caused it to be eligible for PCA dialogs when the user exits the EXE.  However, PCA is designed to help resolve problems with failing legacy setup programs, and this EXE is not a setup.  That left us with another issue we needed to diagnose in order to fully understand the behavior on this system - why was this non-setup EXE being treated as a failing setup?

After discussing this scenario with the Windows application compatibility team, we discovered that Windows Vista monitors events it receives from the UAC virtualization system driver.  If Windows Vista finds from these events that an application attempted to create a folder under the Program Files directory and then attempted to create/copy files into a folder under the Program Files directory and those operations fail, then it will treat the application as a failed installer and trigger a PCA dialog if it does not contain an embedded UAC manifest.

Fortunately, the UAC virtualizaton system driver logs events in the event log that can be used to help narrow down the root cause of this type of issue.  In the case of this system and this EXE, several events were logged from the Microsoft-Windows-UAC-FileVirtualization source.  These events indicated attempts to perform operations on a path under Program Files for an application that has recently been uninstalled.

It turned out that the recently uninstalled application left behind some information in the PATH environment variable and in the registry that caused other programs to attempt to read and write from its installed location under Program Files.

In the case of this EXE, because of these orphaned settings as well as the unrecognized UAC manifest, Windows Vista treated the EXE as a failing legacy setup program and triggered a PCA dialog each time it exited on this specific system.  Other users did not see this behavior because they did not have this other application installed and uninstalled on their systems.

Summary of what we learned from this scenario

We were able to fully resolve this issue by doing the following:

1. Updating the EXE to embed the UAC manifest using resource ID value 1
2. Removing the left over information in the PATH environment variable and in the registry on this system

We also learned a few key things about UAC and PCA on Windows Vista:

1. Embedded UAC manifests must be placed at resource ID value 1 in order to be correctly recognized by Windows Vista
2. Windows Vista treats programs that attempt to create folders and files under Program Files as setup programs
3. Windows Vista logs some events in the event log from the Microsoft-Windows-UAC-FileVirtualization source that can be used to diagnose why a PCA dialog is being triggered for a given EXE

I recently received a comment on my blog asking how to get the DuaScriptGen tool to work on Windows Vista.  I looked into this in more detail, and I found that the duascriptgen.exe.config file included with the tool only listed the .NET Framework 1.0 and 1.1 as supported runtimes.  It looks like I never got around to updating the config file once the .NET Framework 2.0 released.  In addition, I ended up not noticing the underlying issue because the Windows Vista systems that I have tried to run DuaScriptGen on recently both have the .NET Framework 1.1 installed in addition to the .NET Framework 2.0 that is included as a part of the OS on Windows Vista.

To fix this issue and allow DuaScriptGen to run on a Windows Vista system that does not have the .NET Framework 1.0 or 1.1 installed, I added the following line to duascriptgen.exe.config:

<supportedRuntime version="v2.0.50727"/>

I added this above the lines that refer to the .NET Framework 1.1 and 1.0 so that DuaScriptGen will use the .NET Framework 2.0 first if multiple versions are installed on the system.

In addition, I have uploaded a new version of DuaScriptGen that includes this fix to http://astebner.sts.winisp.net/Tools/duascriptgen_v11.zip.  If you want to use DuaScriptGen on Windows Vista, you can choose to download an updated version from this location or manually modify duascriptgen.exe.config with the change described above.

I recently heard from a customer who ran into a series of issues while attempting to deploy the .NET Framework 3.0 to the computers in their network.  This customer was able to resolve each of the issues, but their experience revealed several inaccuracies in the .NET Framework 3.0 deployment documentation that make the deployment process more time consuming and difficult than it should be.  I have reported these issues to the team that maintains this documentation, and they will hopefully update this documentation soon.  In the meantime, I wanted to post more details about the documentation issues in case they are helpful to anyone who is attempting to deploy the .NET Framework 3.0.

Issue 1: Pre-release deployment documentation still available with outdated information

There are two different sets of instructions available on MSDN for deploying the .NET Framework 3.0.  The most up-to-date instructions are located at http://msdn2.microsoft.com/en-us/library/aa964979.aspx and are titled Microsoft .NET Framework 3.0 Administrator Deployment Guide.

The other instructions are located at http://msdn2.microsoft.com/en-us/library/aa480217.aspx and are titled Microsoft .NET Framework 3.0 Deployment Readme.  These instructions include download links for pre-release versions of the .NET Framework 3.0 and instructions that are only valid for pre-release versions of the .NET Framework 3.0.  You should not use these instructions for .NET Framework 3.0 deployment scenarios now that the final version of the .NET Framework 3.0 has shipped.

Make sure that you only use the Microsoft .NET Framework 3.0 Administrator Deployment Guide located at http://msdn2.microsoft.com/en-us/library/aa964979.aspx when preparing to deploy the .NET Framework 3.0.

Issue 2: Incorrect download links for the .NET Framework 3.0

The Microsoft .NET Framework 3.0 Administrator Deployment Guide located at http://msdn2.microsoft.com/en-us/library/aa964979.aspx includes dead and incorrect links for downloading the .NET Framework 3.0 setup packages.

The correct links to use to download the full packages for the .NET Framework 3.0 are the following:

• .NET Framework 3.0 x86 - http://go.microsoft.com/fwlink/?LinkId=70848
• .NET Framework 3.0 x64 - http://go.microsoft.com/fwlink/?LinkId=70849

Issue 3: Incorrect information about OS platforms that require MSXML 6.0

The Microsoft .NET Framework 3.0 Administrator Deployment Guide located at http://msdn2.microsoft.com/en-us/library/aa964979.aspx states that the Microsoft Core XML Services (MSXML) 6.0 package is a prerequisite on the Windows Server 2003 OS, but not on Windows XP.  However, MSXML 6.0 is required on Windows XP and needs to be deployed as a prerequisite prior to deploying the .NET Framework 3.0 package.  Make sure that you include MSXML 6.0 in the prerequisite installation steps on any Windows XP and Windows Server 2003 systems that you are planning to deploy the .NET Framework 3.0 to.

Issue 4: Incorrect command line to extract WCF package

The Microsoft .NET Framework 3.0 Administrator Deployment Guide located at http://msdn2.microsoft.com/en-us/library/aa964979.aspx includes an incorrect command line to create an administrator install point for the Windows Communication Foundation (WCF) component.

It incorrectly states to use the following command line:

wcf.exe /q /c:"msiexec /qb /a wcf.msi REBOOT=ReallySuppress TARGETDIR=c:\wcf"

However, wcf.exe does not support the /c command line switch.  Instead you should use the following command line to create an administrator install point:

wcf.exe /a

The /a switch will display a UI screen that allows you to select the location to use to create the administrator install point.  The path that you specify will be used as the TARGETDIR value when setup creates the administrator install point for you.

If you need an automated way of creating the administrator install point for the WCF package, you can use a two step process where you extract the contents of the package, then run the command line to create the administrator install point.  For example:

• wcf.exe /q /x:c:\wcftemp
• msiexec /a c:\wcftemp\wcf.msi REBOOT=ReallySuppress TARGETDIR=c:\wcf

Issue 5: RGBRAST component cannot be deployed correctly using Group Policy

The MSI for the Software rasterizer for the Microsoft DirectX 9.0 Software Development Kit (SDK) package cannot be installed using Group Policy.  The errors in this scenario have been documented in this MSDN forum post and in one of my previous blog posts.

This package is only required on Windows XP, and it installs one file to %windir%\system32 that does not get uninstalled.  As a result, you can workaround this problem by manually deploying the file included in this MSI (named rgb9rast_2.dll) to %windir%\system32 on any Windows XP systems that you plan to deploy the .NET Framework 3.0 to.

Ian Dixon has published episode 126 of the Media Center Show, and Niall Ginsbourg is Ian's guest on this episode.  Niall has developed several Windows Media Center applications (such as Big Screen Photos and Big Screen Headlines among others).  In addition, he is a community development expert on the Windws Media Center Sandbox forums.

Niall discusses several Media Center development topics with Ian on the show, including best practices he applies while developing applications and some information about the applications he has created or is currently working on.

You can check out the following links for more information about Media Center Show episode 126:

• Overview post with the timeline for episode 126 - http://iandixon.spaces.live.com/Blog/cns!36983156CAA83EA9!2375.entry
• Direct download link for episode 126 - http://thedigitallifestyle.com/audio/TDL_MediaCenter_20071011_126.mp3
• Mobilewares website where you can download and learn more about Niall's Windows Media Center applications - http://mobilewares.net/

I encourage you to check out this episode of the Media Center Show if you are interested in developing applications for Windows Vista Media Center.

I previously wrote a blog post describing a set of supplemental Windows Vista Media Center project templates for Visual Studio 2005 and 2008 that can be installed on a system that already has the Windows Vista Media Center SDK installed to give you some development options that are not currently available in the SDK.

I have updated this set of project templates to include the following changes from the initial package that I posted:

• Added a C# template for creating a Media Center background application and integrated it into both VS 2005 and VS 2008.  These are modeled after the steps that Charlie Owen listed in this blog post.
• Integrated the C# template that is included in version 5.2 of the Windows Vista Media Center SDK with VS 2008 (the SDK currently only integrates it with VS 2005)
• Renamed the templates so their purposes make more sense in the New Project dialog in the VS IDE (and added better icons courtesy of Charlie).  They are now named "Windows Media Center Application" (for the template based on the step-by-step guide) "Windows Media Center Application - Fundamental" (for the simpler template without as much pre-created code and MCML included) and "Windows Media Center Application - Background."
• Updated the installer to check for the existence of the Windows Vista Media Center SDK because some of the project templates require the McmlVerifier tool for a post-build step (and that tool is installed by the SDK)

The updated supplemental project template MSI is available at http://astebner.sts.winisp.net/Tools/mce_project_templates.zip.  If you install it on a system that had the previous version installed, it will automatically upgrade you to the new version.  In addition, this MSI is designed to co-exist side-by-side with the Media Center SDK, so installing and uninstalling either one will not harm the other.

I'm working with Charlie so that we can hopefully include some of these new templates in a future edition of the SDK as well.  If/when that happens, I'll make sure that side-by-side co-existence continues to work there too.

A new cumulative update package for Windows Vista Media Center has been released this week.  This update is called the October 2007 Cumulative Update for Media Center for Windows Vista and is also known as KB941229.  It is available for download in x86 and x64 versions.

The October 2007 Cumulative Update includes the following fixes:

• All of the fixes previously included in the June 2007 Cumulative Update
• An issue that affects digital cable card components when you use Scientific Atlanta cable cards
• Interaction issues that occur between a Windows Vista Media Center PC and an Xbox 360 that is being used as a Media Center extender
• Autolaunch issues that can occur with video CD (VCD) media 
• Several bug fixes for the Media Center platform to help Media Center applications (in addition to the ones previously available in the June 2007 Cumulative Update)

Here are some links for the October 2007 Cumulative Update:

• Knowledge base article - http://support.microsoft.com/kb/941229
• Download location for x86 package - http://www.microsoft.com/downloads/details.aspx?FamilyId=48477121-4427-483D-8309-4C18DE611BD4
• Download location for x64 package - http://www.microsoft.com/downloads/details.aspx?FamilyId=DC17DA0A-46A9-4CD7-88F1-E8C576F8E585

In addition, there are 3 other cumulative updates being released for Windows Vista at the same time as the October 2007 Cumulative Update for Media Center.  They help address issues reported by customers related to reliability, compatibility, stability, security and performance of various features in Windows Vista.  The following links contain more information about the fixes included in each of these additional updates and allow you to directly download and install them if you choose to:

• Cumulative Update Rollup for USB Core Components in Windows Vista (KB941600) - http://support.microsoft.com/kb/941600
• Update for Windows Vista (KB941949) - http://support.microsoft.com/kb/941649
• Update for Windows Vista (KB941651) - http://support.microsoft.com/kb/941651

As announced last night on the Media Center Sandbox blog, a new application for Windows Vista Media Center has been released.  The application, named PowerPlaylist, adds a custom strip to the Windows Vista Media Center start menu with up to five tiles.  Each tile represents an audio, slideshow and/or visualization combination which will start when the tile is selected.  PowerPlaylist is configured via an XML data file, and the application includes an editor to customize the information in the data file, including the title of the custom Start Menu strip and the name, image, audio source, slideshow folder and visualization for each tile.

PowerPlaylist has been released on CodePlex, and you can download x86 and/or x64 MSI-based installers if you want to try out the application.  You can also download source code (licensed with the Microsoft Permissive License) if you want to see how the application works behind the scenes, modify it to add features, fix bugs, etc.

Here are some links for more information about PowerPlaylist:

• CodePlex project front page - http://www.codeplex.com/powerplaylist
• Releases page (where you can download the x86 and x64 installers) - http://www.codeplex.com/powerplaylist/Release/ProjectReleases.aspx
• Source code download page - http://www.codeplex.com/powerplaylist/SourceControl/ListDownloadableCommits.aspx

I have heard from a couple of customers recently who have hit an error while trying to install Visual Studio 2005 in unattended mode using an INI file.  In their scenarios, the setup process started and then almost immediately exited and VS ended up not installing correctly. 

On their systems, VS 2005 unattended setup produced a log file named %temp%\AdminBaselineErrorLog.txt that showed errors like the following:

Setup discovered the following problems:

1. The file myfile.ini was created for  operating system. Please contact your administrator to obtain the file for your operating system, Win .NET.

2. The file myfile.ini was created for  processor type. Please contact your administrator to obtain the file for your processor type, AMD64.

In the cases I've seen so far, the customers were launching VS setup in unattended mode using a command line like the following:

<VS install location>\Setup\setup.exe /unattendfile myfile.ini

The key thing here is that in this command line, the path to the INI file only listed the file name and not the fully qualified path, including the directory where the INI file was located.  When a relative path to the INI file is used, the GetPrivateProfileSection and GetPrivateProfileString APIs that VS setup uses behind the scenes to read the contents of the INI file will fail, and the values for operating system and processor architecture will be set to default blank values.  This causes VS setup to not be able to identify what OS and processor architecture the INI file should apply to, and setup exits without attempting to install anything.

The workaround in this type of scenario is to change the command line being used to launch VS setup in unattended mode to pass in the full path to the INI file.  For example:

<VS install location>\Setup\setup.exe /unattendfile \\myserver\myshare\myfile.ini

or

<VS install location>\Setup\setup.exe /unattendfile d:\temp\myfile.ini

Recently, I started in a new role here at Microsoft - I have moved to the XNA Community Gaming Platform (CGP) team.  At a really high level, the XNA CGP team creates a set of tools and libraries to enable rapid development of games for the PC and the Xbox 360 using Visual C# Express 2005 (and with the upcoming 2.0 version, the standard and higher editions of Visual Studio 2005 as well).

I'm really excited to join the XNA team because of the focus on development tools, direct community engagement and grassroots efforts to help encourage more people to try out computer programming.

I've found some useful information online as I've started learning about the features that my new team provides:

• XNA Creators Club Online - http://creators.xna.com/
• XNA community forums - http://forums.xna.com/
• XNA team blog - http://blogs.msdn.com/xna
• XNA Game Studio Express 1.0 refresh download location - http://www.microsoft.com/downloads/details.aspx?FamilyId=12ADCD12-7A7B-4413-A0AF-FF87242A78DE
• XNA Game Studio 2.0 announcement - http://blogs.msdn.com/xna/archive/2007/08/13/announcing-xna-game-studio-2-0.aspx
• Gamefest 2007 information - http://www.xnagamefest.com/conference_details.htm

I also found a really interesting 2-part interview with Chris Satchell, the general manager of the organization that includes the XNA CGP team, that provides some interesting insights about possible future directions for the team:

• http://www.developmag.com/interviews/72/XNAbling-everyone-Part-1
• http://www.developmag.com/interviews/73/XNAbling-everyone-Part-2

As I settle into my new role, I'll be posting more about XNA community games features on my blog in addition to the other types of topics I've typically posted about in the past (from general setup creation and debugging issues to WiX to Visual Studio and the .NET Framework setup/deployment to Windows Media Center development and deployment).