Thoughts about setup and deployment issues, WiX, XNA, the .NET Framework and Visual Studio
All postings are provided AS IS with no warranties, and confer no rights. Additionally, views expressed herein are my own and not those of my employer, Microsoft.
I have heard from a few customers (inside and outside of Microsoft) who have had problems uninstalling previous beta versions of SQL Express via Add/Remove Programs or via the cleanup tools we have released (located here and here). These customers have seen unexpected errors in the datastore related to the actions named RestoreSetupParams and/or Write_CommitFlag. The exact error message states that setup is unable to write property into the cache: IsClustered and unable to write property into the cache: flagCommit.
I haven't narrowed down the exact sequence, but these uninstall errors are caused by uninstalling beta versions of SQL 2005 and/or VS 2005 in specific orders. The officially recommended uninstall order for these products can be found at this location. However, this order is not enforced via the Add/Remove Programs control panel and it is pretty easy to overlook the readme and uninstall in alphabetical order or some other random order and get into this state.
If you encounter either or both of the above error dialogs, you can use the following steps to resolve the errors:
After running smartmsizap to cleanup each of the SQL 2005 products left behind on your machine, you should be able to successfully install later builds of SQL Express and/or VS 2005.
<update date="11/26/2005"> Added text descriptions of the error messages to make it more likely that this blog post will be found from internet search engines because I have heard from a lot of customers who have run into this error but not found this blog post. Also modified the uninstall instructions to use the smartmsizap tool that I had not yet written at the time that I originally wrote this blog post. </update>
<update date="4/14/2009"> Fixed broken link to the smartmsizap tool and removed broken image links. </update>
<update date="8/27/2010"> Fixed broken link to the VS 2005 uninstall instructions and the TTool.zip tool. </update>
I have seen questions from fellow Microsoft employees regarding how to install Windows XP Media Center edition on a brand new computer using the OS installation CDs. This question has very rarely been asked by customers outside of Microsoft because Media Center is typically only available via an OEM reseller and comes pre-installed on the computer. There are some cases where customers can buy machines with the installation CDs but do not have the OS installed, or the OEM provides recovery media on CD instead of on DVD. This process is a little bit tricky so I decided to list the steps to install Media Center on a clean partition from CD.
The process to install Media Center is different from the process to install XP Home/Pro because Media Center spans 2 CDs whereas the standard Windows XP Home/Pro product fits on a single CD. It requires the following 2 steps that are different from standard XP Home/Pro OS setup:
Launch OS setup with a special command line switch
The following command lines can be used to launch Media Center setup from CD:
The /makelocalsource:all and /2 command line parameters cause winnt32.exe and winnt.exe to copy the contents of CD1 and CD2 to the local hard drive at the beginning of OS setup. If you fail to do this you will receive disk swap prompts during Media Center (or Tablet PC) OS installation.
Enter a valid product key that matches the OS type you want to install
After launching setup with one of the above command line parameters, the other step required to install Media Center instead of the standard XP Home/Pro OS is to enter a valid Media Center product key when prompted during OS setup. Doing so will cause OS setup to install the .NET Framework 1.0 and Media Center components in addition to the standard XP Home/Pro components. It will also cause your OS to be branded appropriately (for example - the left side of the start menu if you have your desktop configured for Windows Classic view will display "Media Center" instead of "Windows XP").
Also, if you enter a Home/Pro product key, OS setup will not end up installing the .NET Framework 1.0 or the Media Center components, and you cannot use Media Center on the Home/Pro OS that you have just installed.
Why the extra steps?!?
Media Center setup ships with the core OS components on CD1 and the Media Center-specific OS components on CD2. If you take a look at Media Center CD1 and compare it to XP Home/Pro CD1, you will see that the contents are nearly identical (with the exception of the EULA file and a couple other small things). CD2 contains Media Center, Tablet PC and .NET Framework bits. The decision about which bits to actually install happens at OS setup time and is controlled by the product key that you enter during OS setup.
Note that even though I only mentioned Media Center, the above OS setup behaviors apply equally to Tablet PC. Both Media Center and Tablet PC share the same underlying OS setup design and both require the extra command line switches and specific product key to be entered during setup to install the correct bits.
I have heard from several customers who have had problems trying to repair the .NET Framework or install a .NET Framework service pack and saw an error dialog asking for the source location for tmpXXXX.tmp. I wanted to try to explain why this can happen and also describe a way that I normally recommend to fix this issue.
Why does this happen?
The .NET Framework hotfix setup wrapper creates patch files on the fly in the %temp% directory that are named tmpXXXX.tmp (where XXXX is a randomly generated ending), and then deletes the file after applying the patch. When attempting to install any .NET Framework hotfix or repair the .NET Framework, Windows Installer will perform a component health check. If any of the components installed as part of the patch have been damaged/deleted, Windows Installer will trigger a repair and search for the files in the original install location. In this case, the original install location does not exist because it was deleted from %temp%.
How can I workaround this?
I posted a complete set of steps that you can use to clean up your system and reinstall the .NET Framework at http://blogs.msdn.com/b/astebner/archive/2008/03/07/8108332.aspx.
<update date="5/6/2011"> Removing the old instructions in this post and pointing to updated steps. </update>
I got a question from a customer this week asking how they could modify the default installation path in their MSI-based setup package based on a value they wanted to retrieve from the registry. Typically this kind of modification is desired if your setup shares files/components with another MSI, and that other MSI can be installed to non-default locations by another setup package. The steps to accomplish this are roughly the following. Please note that I am basing this algorithm on how we accomplish this inside of Visual Studio setup (I also described what happens behind the scenes in VS setup in more detail here). There may be alternative ways to accomplish the same result.
I was helping a customer last week who wanted to push the .NET Framework 1.1 to a series of computers in a corporate network, but wanted to show some kind of progress UI on the client computers. I realized that we added an unattended switch to the setup wrapper for .NET Framework 1.1 based on some customer feedback from 1.0.
You can run .NET Framework 1.1 setup with the following command line switches to install using MSI basic UI:
dotnetfx.exe /q:a /c:"install.exe /qb /l"
This command line will cause the .NET Framework 1.1 to install with no user interaction required, but a small MSI progress bar will appear during installation so the user knows that something is happening on their machine. Note that as stated above, this /qb switch was added in .NET Framework 1.1, so this switch will not work in 1.0 setup.
Those of you with some knowledge of MSI command line parameters might ask why not just have customers extract the contents of dotnetfx.exe and then install netfx.msi directly. Or better yet, why not have them run dotnetfx.exe /q:a /c:"msiexec /i netfx.msi /qb /l*v" or something like that to achieve the same effect without needing to write new code to support the /qb switch for install.exe.
The answer to this is that we want customers who install the .NET Framework 1.0 and 1.1 to use install.exe to do so. There are several reason for this:
As a side note, in the .NET Framework 2.0, we implemented a custom action to install assemblies using fusion APIs directly, in part to eliminate the "chicken and egg" problem. As a result, we see nearly no 1935 errors while installing .NET Framework 2.0. The install.exe setup wrapper still stops the Windows Installer service before and after installation because of possible interactions with other versions of .NET Framework setup due to copies of other versions of fusion being loaded into memory during the 10 minute window that the service would otherwise stay running after installation. Also, .NET 2.0 does not carry Windows Installer 2.0 because of the high market penetration of Windows Installer and because Windows Installer 3.1 has been posted as a mandatory update on Windows Update. That makes bullet #2 above much less of an issue for administrators and 3rd party developers. However, we still recommend installing .NET Framework 2.0 using the install.exe wrapper even though we've improved the scenario of installing using netfx.msi directly.
Even though we recommend using install.exe to install the .NET Framework 1.1 and 2.0, setup will work in most cases when running the MSI directly. It requires more care on the part of administrators or 3rd party setup developers who redistribute the .NET Framework. In controlled environments (such as OEM pre-installations of the .NET Framework), it is much easier to control cases where the Windows Installer service might be running and shut it down separately by running net stop msiserver for example.
A couple of months ago I posted some instructions about how to repair the OCM version of the .NET Framework 1.1 that ships as part of the OS on Windows Server 2003 (at this location). When I wrote that post, I knew that there would eventually be questions about how to perform a similar repair for the version of the .NET Framework 1.0 that ships as part of the OS on Windows XP Media Center Edition and Tablet PC Edition, but I skipped those instructions at the time because they are more complicated. Yesterday, I came to work and found a comment on one of my blog posts asking that very question, so now it is time to list these steps as well. I apologize in advance for the complicated nature of these steps - I promise that if we knew then what we know now we would have engineered our OCM setup to make this easier.
Here are the steps required to manually repair the .NET Framework 1.0 on Media Center and Tablet PC:
Note, you can verify that the .NET Framework 1.0 component was repaired by looking at the contents of the log file named %windir%\netfxocm.log. You should see entries towards the end indicating that several files were installed to the GAC, type libraries were re-registered, performance counters were re-registered, etc.
<update date="8/19/2007"> Added more specific details about where to browse for .NET Framework 1.0 source files </update>
<update date="6/24/2009"> Fixed broken download links. </update>
After I posted these instructions for how to correctly install Media Center from CD, I got a mail from Charlie Owen with a link to a blog item he posted back in February that I hadn't seen at the time I wrote my post. His post provides links to several really nice articles he wrote about how to configure a Media Center PC from scratch. Here is a list of the topics he wrote about:
Interestingly enough, his setup document instructs you to boot directly from Windows XP Media Center Edition 2005 CD1 to start OS setup and doesn't cover the command line switches I wrote about in my blog post. I'd recommend using those instructions instead of trying to launch OS setup yourself unless there is some reason you need to launch OS setup directly because it is less error-prone that way.
I strongly encourage anyone looking at building a Media Center PC to take a look at these docs if you haven't already....
Important note - the steps in this blog post have typically only proven useful in cases where a previous beta of Visual Studio 2005 was installed on the system prior to installing the final release of VS 2005. If you have never had a beta of VS 2005 on your system and are encountering package load failure errors, these steps will most likely not help. In that type of scenario, I recommend running devenv.exe with the /log switch (described in this MSDN topic) to create a log file of the packages it tries to load and then search in that log file for errors and warnings to help narrow this issue down further.
A few customers have contacted me because they have seen the following package load failure error message after uninstalling VS 2005 beta 1 and upgrading to the VS 2005 July or August Community Tech Preview (CTP):
They have all tried running the VS 2005 beta cleanup tool (located here) but did not have any success. One of the fixes that the VS 2005 cleanup tool makes is to delete some native images, and the directory that it uses to delete the native images from is specific to VS 2005 beta 2. However, I recently figured out that this fix needs to be modified to work correctly for post beta 2 CTP builds. That means the current version of the cleanup tool will fix this package load error if you upgrade from beta 1 to beta 2, but not if you upgrade from beta 1 to a post beta 2 build such as the July or August CTP.
There are a couple of options for how to fix this issue:
1. You can use these manual steps:
The above steps will remove an incorrect native image from the native image cache and then re-run NGEN.exe to generate a new set of correct native images.
2. You can download a work-in-progress version of the updated VS 2005 cleanup tool
This new version of the cleanup tool will automatically fix this issue on both VS 2005 beta 2 and post-beta 2 builds. Please note that the cleanup tool is still being enhanced to handle additional known issues and should be used at your own risk. Please provide feedback about this tool at this link (my contact page) and/or at this link (Hong's contact page).
<update date="4/11/2008"> Added a caveat to the top of this post indicating that it is typically only useful on systems that had a previous beta version of Visual Studio 2005 installed. </update>
We have seen some cases where the new VS 2005 cleanup tool fails to fully remove previous VS 2005 beta products. Behind the scenes, the cleanup tool searches for a list of known previous beta product codes, and if it is found, it will try to run msiexec /x for each product code that is found to be installed on the machine. However, there are some cases where msiexec /x fails to uninstall the product and additional steps need to be taken.
In order to address this set of scenarios, I have been working on a standalone tool that can be run as an action by the cleanup tool or as a standalone tool. There is a version of this tool, called smartmsizap, that can be downloaded from this location. In order to use the tool, you can run smartmsizap.exe /p {product_code}. It uses msiexec /x and msizap behind the scenes.
I'm interested in getting feedback from anyone reading this regarding the logic behind the scenes for this tool. Here is a rough outline of what it does behind the scenes:
I'm still testing this out in various scenarios as I run into weird dirty machine states. But I'm curious if there are any holes in this logics that I've missed so far. Let me know what you think by posting comments or contacting me.
Once we get some additional testing, we'll get this exe integrated into a later version of the cleanup tool to make it able to cleanup additional scenarios that it currently can't resolve because it does not run msizap.exe currently.
<update date="4/1/2009"> Fixed broken link to smartmsizap tool. </update>
I got a comment from a customer asking about the availability of some Windows features such as Internet Explorer and Windows Media Player on a Windows XP Media Center 2005 computer that they purchased from an OEM. This comment made me realize that it is likely that not everyone out there is aware of a control panel applet called Set Program Access and Defaults (or SPAD for short) that can be used in Windows 2000 and Windows XP to control the default behavior of the OS for certain types of middleware applications such as email clients, web browsers, media players, instant messaging clients, etc. The SPAD applet also has specific items that can be used to show or hide individual Media Center experiences (DVDs, music, radio, TV, videos and Online Spotlight).
If you are interested in taking a look at the SPAD applet, you can get to it by opening the Add or Remove Programs control panel on a Windows 2000 Professional, Windows XP, Media Center or Tablet PC OS. There should be an item on the left side of the Add or Remove Programs control panel called Set Program Access and Defaults. Clicking this will open the configuration window for SPAD. You can use this to specify default programs to use for various activities and also enable or disable access to programs. A common usage of SPAD is to hide all entry points to Internet Explorer or Windows Media Player for example.
If you look at the Custom settings for the SPAD configuration control panel on a Windows XP Media Center 2005 machine, it looks like the following:
Applications that fit into the categories in the SPAD configuration control panel can install registry keys that will cause their applications to appear in this control panel if they want to. The registry values that control what appears in the SPAD control panel are located at HKEY_LOCAL_MACHINE\Software\Clients, and there is some good documentation regarding how to register an application to work correctly with the SPAD control panel in this MSDN article if you are interested.
There is also some more in-depth information about the SPAD control panel in this article.
I wrote this post a couple of months ago describing how to install an assembly to both the GAC and the local file system in the same MSI. Since then, I've been asked a couple of follow-up questions by folks who read my blog post and also by internal Microsoft setup developers. Here is an interesting question that I wanted to share. I helped out a developer who is using WiX to create their MSI. They initially created a single component with 2 copies of the file but the MSI could not be created. This is because Windows Installer does not allow you to install multiple assemblies in the same component (except in the rare case that you have a multi-module assembly). The developer then followed the guidelines of creating 2 separate components to install the file - one for the local file system and one for the GAC. The snippet of their WiX XML looks like this:
<Component Id="foo.dll" Guid="23C421A5-B2AA-415b-9359-B3CC2F46D155" DiskId="1"> <File Id="foo.dll" KeyPath="yes" Name="foo.DLL" LongName="foo.dll" src="$(var.FileRoot)\foo.dll" /></Component><Component Id="foo_GAC.dll" Guid="73205F15-F5D9-4EAE-A442-025B06B1ECBF" DiskId="1"> <File Id="foo_GAC.dll" KeyPath="yes" Assembly=".net" ProcessorArchitecture="msil" Name="foo.dll" LongName="foo.dll" src="$(var.FileRoot)\foo.dll" /></Component>
However, when the developer ran ICE validation on the resultant MSI, it came up with the following errors:
ICE30 ERROR The target file 'foo.dll|foo.dll' is installed in '[ProgramFilesFolder]My Folder\' by two different components on an LFN system: 'foo_GAC.dll.77A12173_4086_4E29_AEFF_562F22878D9A' and 'foo.dll.77A12173_4086_4E29_AEFF_562F22878D9A'. This breaks component reference counting.ICE30 ERROR The target file 'foo.dll|foo.dll' is installed in '[ProgramFilesFolder]My Folder\' by two different components on an LFN system: 'foo_GAC.dll.77A12173_4086_4E29_AEFF_562F22878D9A' and 'foo.dll.77A12173_4086_4E29_AEFF_562F22878D9A'. This breaks component reference counting.
The problem ended up being that both components were authored to install to the same directory, which is a little misleading since the copy of the file that gets installed to the GAC does not actually get installed to the directory listed in the Component table of the MSI. The way that the Visual Studio MSI package handles this is to create a dummy directory named \GAC underneath the local directory that each duplicated assembly is installed to on the local file system. Then the GAC version of the component can be marked to "install" to that dummy directory, which will allow the ICE30 test to pass.
Starting approximately this past weekend, I've started hearing from a few folks who have had questions or problems installing some of the various versions of the products given out to attendees at PDC 2005 last week. Rob Relyea did a really nice job of outlining how to configure a WinFX development machine using the DVDs given out at PDC or using bits available for download from the web.
I wanted to emphasize the key points that I've gathered by looking at the various packages given out at PDC, reading Rob's notes, and talking to some customers who have run into problems so far:
Another problem I have heard of that is related to the development tools passed out at PDC involves the beta version of Microsoft codename Max. This Max beta is built on top of WinFX and it requires the September CTP of the WinFX runtime, which was given out at PDC and is available on the web. The Max setup package will attempt to download and install the WinFX runtime if it is not already installed, but it does so by trying to download the entire 40+ megabyte package instead of using the web download bootstrapper that the standalone WinFX setup package uses. If you encounter failures during download of Max, I suggest downloading and installing the WinFX runtime directly from the WinFX download page because the link on that page points to the WinFX setup bootstrapper. The WinFX bootstrapper is more resilient to network hiccups (it has logic to retry the download several times before giving up), offers richer progress UI, and will skip downloading the .NET Framework 2.0 beta 2 to minimize bandwidth if it is already present (which it will be on Vista build 5219 from PDC). I have heard of a few Max setup failures that were simply the result of a download hiccup during that 40+ megabyte download of the WinFX runtime and a lack of retries within the Max bootstrapper. I have heard of a few others that were the result of a lack of progress feedback during Max download and user cancellations as a result. Hopefully future versions of these setup packages will work a little smoother together in the future. :-)
Please feel free to contact me or post comments if you have any questions or run into any issues with any of the PDC software (or any non-PDC versions for that matter...) and I'll try my best to help out.
A while back I posted some sample code in C++ that can be used to detect whether or not the .NET Framework 1.0 or 1.1 is installed, and if so, what service pack is installed. I've been meaning to update the code to detect 2.0. Now that the final version number for the .NET Framework 2.0 has been locked to v2.0.50727, I don't have any excuse to put this work off any longer. Plus I got an email from a customer asking about this detection, and that finally provided the motivation I needed to do this. :-) You can find updated detection code for the .NET Framework that includes 2.0 at this location. Hope this helps!
The officially supported uninstall tool for previous beta versions of VS 2005 has been posted on MSDN. You can download it at this location. This uninstall tool automates the instructions located here. Hong has previously posted an interim version of this tool on her blog. Please note that this version of the cleanup tool will only work correctly if you currently have VS 2005 beta 2 or a post beta 2 CTP installed and you haven't started the uninstall process to prepare for upgrading to a later build.
If you have already started uninstalling VS 2005 components and did not use the officially recommended uninstall order, you can try out the "find it - fix it" tool that is designed to resolve known issues that can be caused by orphaned files that we know will be left behind if VS 2005 components are uninstalled in the incorrect order. I have heard of a few cases where this tool has crashed when people have tried to run it. If you encounter this, please choose to send the crash report back to Microsoft. This will allow us to debug the failure and fix the tool for future versions.
I stumbled on an interesting project designed to make it easier to teach kids how to program. It is called Kids Programming Language. My nephew turns 2 on October 6, I wonder how much longer I'll have to wait until I can get him started with a learning system like this or like the Visual Studio 2005 express edition starter kits to turn him into a geek like his uncle? :-)
<update 9/29/2005>
I found a couple of additional links talking about KPL:
</update 9/29/2005>
I wrote a post earlier this week about software that was given out to attendees at PDC 2005 and some of the setup issues I have seen or heard of related to that software. One of the topics I touched on was Microsoft codename Max (photo sharing software built on WinFX). A customer posted a comment to that previous post with some useful links that I also wanted to post on my main blog page in case others have problems installing or using Microsoft Max. Here they are:
I just found out that Peter Marcu has established a blog. He is a developer who works on setup for Visual Studio and the .NET Framework, and based on my most recent Google and MSN searches, it appears that he is the only developer on the setup team who has their own blog....