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've posted an updated version of the .NET Framework cleanup tool that now contains an option to remove the .NET Framework 3.5 (in addition to 1.0, 1.1, 2.0 and 3.0). I also added some additional information to be removed when uninstalling the .NET Framework 1.1 (thanks to this comment on one of my other blog posts).
You can use the following links to find more information about the .NET Framework cleanup tool and download it if you need it on your system:
Note - at the time that I am writing this blog post, the .NET Framework 3.5 is still only a beta, so currently the cleanup tool is only able to remove the beta 1 and beta 2 versions of the .NET Framework 3.5. I will update the tool in the future when future builds of the .NET Framework 3.5 are released publicly.
<update date="5/19/2008"> Added an alternate download location for the cleanup tool in case the first site is down. </update>
Steven Harding recently posted an update about a couple of the projects he's been working on in this post on his Digital Lifestyle Developer Blog, and I wanted to link to it here and encourage folks to check out these applications.
Updated alpha version of Yougle Vista
The first is an updated alpha version of Yougle Vista. You can use Yougle Vista to browse and view community video from sources such as YouTube, Google Video, MSN Soapbox and others. You can find information about Yougle Vista at http://www.push-a-button.com.au/products/mce/vista/youglevista/index.php.
As stated in the blog post, the Yougle Vista application is still in alpha and you may encounter some bugs, in particular on 64-bit versions of Windows Vista. I've been using Yougle Vista for a few weeks on my 32-bit Windows Vista Ultimate system and the only real issue I had was the initial hurdle of getting it running in the first place. Once I installed a recent build of the FFDShow codec pack, it worked fine in most scenarios. I highly encourage you to check out this application, even in alpha form.
Poker game timer
The second application is a poker game timer. It can be downloaded from http://www.push-a-button.com.au/downloads/BlindTimerSetup.msi and keeps track of blinds, antes, and time until they will increase. It includes spoken announcements of blind increases and warnings as the timer is about to expire. I'm not a big poker player myself, but if you are, this application could come in handy for you.
Recently, we have been hearing reports from customers who have installed the .NET Framework 3.5 beta 2 and then visited Windows Update and were offered .NET Framework 3.0 hotfix KB932471, but it continually fails to install.
The .NET Framework 3.5 contains an updated version of the .NET Framework 3.0, and that updated version of 3.0 contains this hotfix already. Unfortunately, there was some incorrect detection information in the Windows Update logic that is used to decide whether or not to offer this hotfix to a system.
If you have the .NET Framework 3.5 beta 2 or later installed and run into issues while trying to install KB932471 (either from Windows Update or by downloading it directly from the Microsoft Download Center), you can safely ignore this failure and just skip installing this hotfix since the equivalent fix is already a part of the version of the .NET Framework 3.5 that you have on your system.
The Windows Update authoring logic that is causing this error is in the process of being fixed, and will be refreshed on the live Windows Update site in the near future.
I just noticed this post on Bret Grinslade's blog that I wanted to link to here to help raise visibility. In that post, Bret describes how to gather more information about any installation failures that you might encounter while installing a beta version of Visual Studio 2008 and the .NET Framework 3.5, and also some resources where you can go to find more information about known issues and workarounds.
Here are some useful links that were presented in that blog post. If you are running into any problems installing VS 2008 or the .NET Framework 3.5, hopefully they will be helpful to you:
Gathering information from your system and reporting bugs if you run into setup issues
Finding information about known issues and workarounds
As reported this weekend by the Windows Installer team and Heath Stewart, the beta of Windows Installer 4.5 (including binaries, headers, libraries and help files) has been posted to the Connect site for members of the beta program to download and try out. Here is some useful information about the Windows Installer 4.5 beta program:
As described in this blog post, a new version of the Windows Vista Media Center SDK was recently released. That version of the SDK contains a new C# project template. I just noticed a couple of new post on the Media Center Sandbox blog that describe some useful modifications that can be made to this project template in order to create different types of Windows Vista Media Center applications:
I encourage you to check out these posts to see step by step instructions for these customizations that can be made to the standard Windows Vista Media Center SDK project template.
The .NET Framework 3.5 beta 2 includes updates for the .NET Framework 2.0 and 3.0. Since the .NET Framework 2.0 and 3.0 are installed as OS components on Windows Vista, the updates are delivered as Windows Vista hotfix packages. We have seen some issues related to the installation of these .NET Framework 2.0 and 3.0 updates during .NET Framework 3.5 beta 2 setup that have turned out to be caused by known bugs with the Windows Vista hotfix installation engine. The following items describe the issues we have seen so far with the Windows Vista hotfix installation engine and how to work around them to unblock .NET Framework 3.5 beta 2 installation:
Issue 1 - Installer encountered an error 0x8007177f. This machine is disabled for file encryption.
Aaron Ruckman described this issue in this blog post. If you encounter this issue during .NET Framework 3.5 setup, the .NET Framework 2.0 update package will fail with error code 6015. If you are running the .NET Framework 3.5 setup directly, you will see an error like the following in the setup error log:
[07/01/07,11:30:00] Microsoft .NET Framework 2.0SP1 (CBS): [2] Error: Installation failed for component Microsoft .NET Framework 2.0SP1 (CBS). MSI returned error code 6015
If you are running VS 2008 setup (which chains the .NET Framework 3.5 as a prerequisite), you will see an error like the following in the setup error log:
[07/01/07,11:30:00] Microsoft .NET Framework v3.5: [2] Error code 6015 for this component means "This machine is disabled for file encryption."
This error means that there is a domain policy in effect that prevents file encryption using the Encrypting File System (EFS) from working. There is a Windows Vista hotfix available to correct this issue, and information about obtaining it can be found in the knowledge base article located at http://support.microsoft.com/kb/933595.
Issue 2 - Installer encountered an error 0x80073712.
On some Windows Vista systems, it is possible that the OS component store has gotten into a corrupt state. When this happens, the Windows Features control panel will be empty, and any Windows Vista hotfixes that you attempt to install will indicate that they are not applicable. If you are running the .NET Framework 3.5 setup directly, you will see an error like the following in the setup error log:
[07/01/07,11:30:00] Microsoft .NET Framework 2.0SP1 (CBS): [2] Error: Installation failed for component Microsoft .NET Framework 2.0SP1 (CBS). MSI returned error code 1
[07/01/07,11:30:00] Microsoft .NET Framework v3.5: [2] Error code 1 for this component means "Incorrect function."
There are steps in the knowledge base article at http://support.microsoft.com/kb/931712 that can be used to update the registry in order to repair the Windows Vista component store in order to work around this error. To summarize the steps listed in that knowledge base article, you can do the following:
After running this command, you can re-run .NET Framework 3.5 or VS 2008 setup and hopefully resolve this error.
Note that return code 1 from a Windows Vista hotfix package means that the package is not applicable on the system. However, this StoreDirty registry value is not the only possible cause of this error for .NET Framework 2.0 and 3.0 hotfixes. The same error can appear in the setup logs if you previously had the beta 1 version or some pre-beta 2 CTP version of the .NET Framework 3.5 installed on your Windows Vista system and the old beta was not uninstalled prior to installing beta 2. If the above workaround does not help, you can try the following to remove any pre-beta 2 versions of the .NET Framework 2.0 and 3.0 update packages for Windows Vista:
I just noticed a set of steps that have been posted on the Windows Installer team blog that can be used to sign up for the Windows Installer 4.5 beta. If you are interested in trying out this beta and haven't signed up yet, I encourage you to check out http://blogs.msdn.com/windows_installer_team/archive/2007/08/21/walkthrough-for-signing-up-for-windows-installer-4-5-beta.aspx for more information.
Currently, signing up for the 4.5 beta will allow you to access some white papers about agility in software packaging and how Windows Installer 4.5 can help achieve agility goals. In addition, according to this post, the Windows Installer 4.5 beta will be available for download "any day now" to members of the beta program.
I've posted an updated version of the .NET Framework cleanup tool that now contains an option to remove the .NET Framework 3.0 (in addition to 1.0, 1.1 and 2.0). I also embedded a UAC manifest in this version so it will prompt you for elevation when running the cleanup tool on Windows Vista.
One important note - the cleanup tool does not allow you to remove any versions of the .NET Framework that are installed as part of the OS that it is being run on. So, it does not support removing the .NET Framework 1.0 on Windows XP Media Center Edition or Windows XP Tablet PC Edition, removing the .NET Framework 1.1 on Windows Server 2003, or removing the .NET Framework 2.0 or 3.0 on Windows Vista.
A new beta version of the TV Toolbox application for Windows Vista Media Center has been released on the MCEDev.com site. You can check out the following links for more information about TV Toolbox:
Recently, I helped investigate this Visual Studio 2005 issue reported on the Microsoft Connect site that I wanted to describe here in case anyone reading this blog runs into a similar issue. To summarize that bug report, a couple of customers had installed VS 2005, and they started to notice that a repair would be triggered for VS when they launched Microsoft Outlook.
How to reproduce this issue
In the cases that I investigated, the customers had large-capacity USB hard drives connected to their systems. The repair would occur if they disconnected or powered off their USB hard drive, and it would not occur if the USB hard drive was connected.
How to workaround this issue
There are a few possible workarounds for this type of repair:
1. Uninstall VS, then re-install it with the external hard drive disconnected
2. Leave the external hard drive connected when starting Outlook
3. Use the following steps to remove a couple of registry values from the system:
Option 3 (deleting the registry values) is the least invasive, and there will not be any functional side effects in VS 2005 or in Outlook if you choose to do this. The values that are listed above are only used by Windows Installer to advertise features, but VS 2005 installs all features locally and does not support advertising, so those registry values do not serve any practical purpose anyway.
More information about the root cause
To track down the exact cause of this repair, I had the customers send me some information from their application event logs in order to narrow this down. As I described in this blog post, when Windows Installer triggers a repair of an MSI, it will log a pair of warnings in the application event log with a source named MsiInstaller. The first warning will provide the component GUID for the component in the MSI that triggered the health check, and the second warning will provide the component GUID for the component in the MSI that Windows Installer detected was broken and in need of repair.
There is a component in the VS 2005 product that has been incorrectly authored to try to use the drive with the largest amount of free space (the TARGETDIR property in Windows Installer) as a destination location. In these cases, this drive resolved to the USB hard drive, and when that drive was disconnected or powered off, a repair will be triggered in cases where a health check is initiated by the system.
As I described in this blog post, COM objects that are advertised in the Class table of an MSI will cause Windows Installer to perform a health check for the feature(s) that advertise them each time an instance of the COM object is instantiated. The VS 2005 MSI advertises a couple of COM objects that are related to VBA add-in development, and Microsoft Outlook will try to instantiate those COM objects when it is launched in some cases. In these cases, a health check of the VS 2005 product will occur, and the incorrectly authored component will be reported as broken if the USB hard drive is not available.
Fortunately, there are a couple of changes in VS 2008 setup that will prevent this scenario from happening in the future:
Yesterday, I posted a set of instructions that can be used to download the components that make up the .NET Framework 3.5 beta 2 in order to create a network or CD-based install point that will not require any downloads during setup.
As a reader pointed out in the comments of that post, there is a much easier way to assemble this install point if you already have downloaded a copy of VS 2008 beta 2. From your VS 2008 beta 2 DVD, you can go to the \wcu\dotnetframework folder and copy the entire contents to a network share or a CD, and then run dotnetfx35setup.exe from there to install the .NET Framework 3.5 beta 2 without needing to download any additional components.
If you follow the steps in my previous blog post, you will see that you end up assembling the equivalent of that folder structure. Those steps are primarily useful for folks who do not want to have to download the entire VS 2008 beta 2 DVD ISO in order to get access to the .NET Framework 3.5 beta 2 bits to create a network or CD-based install for it.
Note that you can use the same size reduction tricks described in my previous blog post - meaning that you can remove Windows Vista-specific components if your product is not going to support that OS, you can remove downlevel components if your product is only going to support Windows Vista, and you can remove x86 or x64 components if your product is processor-specific. These size reduction steps can be helpful if you are trying to fit the .NET Framework 3.5 beta 2 and your product onto a single CD for redistribution and you're running out of space to fit everything on the disc.
A while back, I wrote a set of instructions that can be used to create a network install point for the Visual Studio 2005 Express Editions (because the only thing available for download is an ISO file that has to be burned to CD, or a web download bootstrapper that requires network connectivity during setup in order to work correctly).
Recently, I was asked how to create a network install point for the .NET Framework 3.5 beta 2 using similar instructions (because currently, the only available downloadable package for the .NET Framework 3.5 beta 2 is a web download bootstrapper and this is not always useful for redistribution scenarios if you want to not require internet connectivity). I decided to write up a set of instructions to do this.
There are a couple of important caveats to keep in mind when using these instructions:
The following steps will allow you to manually assemble an installable layout for the .NET Framework 3.5 beta 2:
.NET Framework 2.0 with Service Pack 1 for Windows XP and Windows Server 2003 (x86)
Make a new folder named c:\netfx35_beta2\dotnetfx20 and download all of the following files into this folder:
Note: The above fwlinks come from the [gencomp760] section of the file baseline.dat that is located inside of dotnetfx35setup.exe.
.NET Framework 2.0 with Service Pack 1 for Windows XP and Windows Server 2003 (x64)
Notes:
.NET Framework 2.0 with Service Pack 1 for Windows Vista (x86)
Make a new folder named c:\netfx35_beta2\dotnetmsp\x86 and download the following file into this folder:
Note: The above fwlink comes from the [gencomp750] section of the file baseline.dat that is located inside of dotnetfx35setup.exe.
.NET Framework 2.0 with Service Pack 1 for Windows Vista (x64)
Make a new folder named c:\netfx35_beta2\dotnetmsp\x64 and download the following file into this folder:
Note: The above fwlink comes from the [gencomp751] section of the file baseline.dat that is located inside of dotnetfx35setup.exe.
.NET Framework 3.0 with Service Pack 1 for Windows XP and Windows Server 2003 (x86)
Make a new folder named c:\netfx35_beta2\dotnetfx30 and download all of the following files into this folder:
Note: The above fwlinks come from the [gencomp780] section of the file baseline.dat that is located inside of dotnetfx35setup.exe.
.NET Framework 3.0 with Service Pack 1 for Windows XP and Windows Server 2003 (x64)
.NET Framework 3.0 with Service Pack 1 for Windows Vista (x86)
Note: The above fwlink comes from the [gencomp752] section of the file baseline.dat that is located inside of dotnetfx35setup.exe.
.NET Framework 3.0 with Service Pack 1 for Windows Vista (x64)
Note: The above fwlink comes from the [gencomp753] section of the file baseline.dat that is located inside of dotnetfx35setup.exe.
.NET Framework 3.5 for all operating systems (x86)
Make a new folder named c:\netfx35_beta2\dotnetfx35\x86 and download the following file into this folder:
Note: The above fwlink comes from the [gencomp301] section of the file baseline.dat that is located inside of dotnetfx35setup.exe.
.NET Framework 3.5 for all operating systems (x64)
Make a new folder named c:\netfx35_beta2\dotnetfx35\x64 and download the following file into this folder:
Note: The above fwlink comes from the [gencomp302] section of the file baseline.dat that is located inside of dotnetfx35setup.exe.
RGB Rasterizer (x86)
Make a new folder named c:\netfx35_beta2\dotnetfx30 and download the following file into this folder:
Note: The above fwlink comes from the [gencomp136] section of the file baseline.dat that is located inside of dotnetfx35setup.exe.
RGB Rasterizer (x64)
Note: The above fwlink comes from the [gencomp137] section of the file baseline.dat that is located inside of dotnetfx35setup.exe.
MSXML 6.0 for Windows XP and Windows Server 2003 (x86)
Make a new folder named c:\netfx35_beta2\dotnetfx30\x86 and download the following file into this folder:
Note: The above fwlink comes from the [gencomp707] section of the file baseline.dat that is located inside of dotnetfx35setup.exe.
MSXML 6.0 for Windows XP and Windows Server 2003 (x64)
Make a new folder named c:\netfx35_beta2\dotnetfx30\x64 and download the following file into this folder:
Note: The above fwlink comes from the [gencomp708] section of the file baseline.dat that is located inside of dotnetfx35setup.exe.
WIC for Windows XP and Windows Server 2003 (x86)
Note: The above fwlink comes from the [gencomp209] section of the file baseline.dat that is located inside of dotnetfx35setup.exe.
WIC for Windows XP and Windows Server 2003 (x64)
Note: The above fwlink comes from the [gencomp210] section of the file baseline.dat that is located inside of dotnetfx35setup.exe.
XPS for Windows XP (x86)
Note: The above fwlink comes from the [gencomp211] section of the file baseline.dat that is located inside of dotnetfx35setup.exe.
XPS for Windows XP (x64)
Note: The above fwlink comes from the [gencomp212] section of the file baseline.dat that is located inside of dotnetfx35setup.exe.
<update date="8/16/2007"> Fixed incorrect links in the .NET Framework 2.0 with Service Pack 1 (x86) section above </update>
Some customers who have installed the recent .NET Framework 2.0 security update (KB928365 and MS07-040) on systems that also have the .NET Framework 3.0 installed have noticed performance degradation in their Windows Presentation Foundation (WPF, also formerly known as Avalon) applications for a short period of time after installing this update.
As Heath Stewart previously described in this blog post, installing an update for the .NET Framework 2.0 causes native images to need to be re-generated for assemblies that depend on any updated .NET Framework 2.0 assemblies (including .NET Framework 3.0 assemblies). The startup performance of some WPF applications depends greatly on having available native images, so if the existing native images are invalid and need to be re-generated, these WPF applications will take longer to load until the WPF native images have been re-generated.
During the initial installation of the .NET Framework 3.0, some of the .NET Framework 3.0 assemblies were flagged as "critical," which will cause native images to be generated at initial setup time. However, that flag is not currently respected in cases where an update to another product causes native images to need to be regenerated. In this case, the security update only modifies the .NET Framework 2.0 product, and does not update the .NET Framework 3.0 product. This causes the 3.0 assemblies to be queued for new native image creation in the background. The NGEN service waits until the system is idle for 5 minutes before processing the background queue.
Heath posted a workaround that can be used to cause the queued native images to be generated immediately so you do not have to wait for system idle time - you can run this command from a cmd prompt (if you are running Windows Vista, you need to use an elevated administrator cmd prompt):
%windir%\Microsoft.NET\Framework\v2.0.50727\ngen.exe executeQueuedItems
Fortunately, as Heath and Surupa (a program manager on the NGEN team here at Microsoft) point out in this blog post, the NGEN team and the .NET Framework setup team are implementing a fix in the next .NET Framework 2.0 update that will ensure that future updates made to .NET Framework 2.0 assemblies will trigger immediate native image re-generation for all critical .NET Framework assemblies (including those that are a part of the .NET Framework 3.0 and not just 2.0). One important thing to note is that since this is a fix in the NGEN service, it will be in effect for updates that ship after the next update (because the first update is needed to change the behavior of NGEN itself, and then any future updates to the .NET Framework will be able to take advantage of that behavior change).
A couple of weeks ago, Microsoft released the beta 2 versions of the .NET Framework 3.5 and Visual Studio 2008, and I posted all of the download links here. This week, Japanese versions of beta 2 have also been released for web download. Here are the download locations for the Japanese versions of the .NET Framework 3.5 beta 2 and Visual Studio 2008 beta 2:
I previously posted an example that allows you to build a WiX-based MSI that will install a Windows Vista Media Center application and create a custom start menu strip. However, there is a limitation in this example (that was pointed out in this post on the Media Center Sandbox discussion forum) that affects the ability to install the application on 64-bit operating systems. This blog post describes the limitations in my previous sample and presents a modified version of that sample that will allow you to build both 32-bit and 64-bit MSIs in order to work around the limitations.
Description of the problem with my previous example
As this forum post describes, you have to directly set registry entries in order to add custom strips to the Media Center start menu (which means that you have to author RegistryKey and RegistryValue elements in WiX). However, if you create a 32-bit MSI and then try to install it on a 64-bit OS, the registry entries will get written to the WOW64 hive (HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft). The 64-bit version of Windows Vista Media Center looks in the 64-bit registry hive and not the WOW64 registry hive when looking for custom start menu strips to load. Therefore, the custom start menu strip will not appear in the Media Center start menu on a 64-bit OS in my previous example.
Example that can be used to solve this problem
To solve this issue, it is necessary to create separate 32-bit and 64-bit installers. It is a little bit tricky to configure all of the settings and attributes that are necessary to create a 64-bit MSI just by reading through WiX and Windows Installer documentation, so I decided to create a WiX 3.0-based example that can be used to build 32-bit and 64-bit MSIs from the same WiX source (WXS) file.
You can download this example from http://cid-27e6a35d1a492af7.skydrive.live.com/self.aspx/Blog%7C_Tools/start%7C_menu%7C_strip%7C_setup%7C_example%7C_with%7C_64bit.zip. I started from my previous 32-bit-only example, and added 64-bit build support. While this sample happens to install a Windows Vista Media Center application, it is intended to help demonstrate the general concepts required to create 64-bit MSIs in WiX.
Changes made in this example to enable 64-bit builds
The new sample includes a single WXS file that is processed twice in order to build 2 different MSIs (one 32-bit and one 64-bit). In order to create a single WXS file that can build both types of MSI, I introduced a WiX pre-processor variable to pass in the name of the processor architecture, and then I added some if/then/else blocks to conditionally set some of the necessary MSI attributes based on whether the MSI being created will be 32-bit or 64-bit.
If you look in the setup.wxs file in the example I posted, you can see all of the changes that I made to enable building a 64-bit MSI by looking for sections of the file that are enclosed in if statements such as the following:
<?if $(var.ProcessorArchitecture)=x64 ?> <Package Description="!(loc.Package_Description)" Comments="!(loc.Package_Comments)" InstallerVersion="200" Compressed="yes" Platforms="x64" /><?else ?> <Package Description="!(loc.Package_Description)" Comments="!(loc.Package_Comments)" InstallerVersion="200" Compressed="yes" /><?endif ?>
In order to set the ProcessorArchitecture variable, I added the following command line parameter when calling candle.exe to compile the WXS file:
"%WIX_BUILD_LOCATION%\candle.exe" setup.wxs -dProcessorArchitecture=%PROCARCH% -out "setup_%PROCARCH%.wixobj"
In addition, I added a second set of commands to call candle.exe and light.exe twice - one with the ProcessorArchitecture value set to x86 and the other with the ProcessorArchitecture value set to x64.
Specific differences between a 32-bit MSI and a 64-bit MSI
The following are the changes that I made in order to be able to create both 32-bit and 64-bit MSIs in WiX:
Where to read more about 64-bit issues related to Windows Installer
When working on this example, I relied heavily on the information in this post on Heath Stewart's blog and the links to Windows Installer MSDN topics that are included in it. If you are looking for more detailed information about how Windows Installer works behind the scenes in 64-bit scenarios, I encourage you to check out this blog post and also the other topics in Heath's 64-bit blog category.
<update date="3/23/2009"> Fixed broken link to sample download location. </update>
Since the release of the .NET Framework 3.5 beta 2 a couple of weeks ago, we have run into a few installation issues that I wanted to let folks know about. The good news is that all of these issues will be fixed in time for the final release of the .NET Framework 3.5, but the bad news is that they can cause beta 2 to fail to install and you may need to apply one of the workarounds listed below.
Issue 1: The IIS Admin Service is disabled
The .NET Framework 3.5 beta 2 will fail to install if setup is being run on a system that has IIS installed, but the IIS Admin service is set to the disabled state.
This issue will cause the following information to be written to the verbose MSI log file for the .NET Framework 3.5 component (named %temp%\dd_net_framework35_MSI*.txt):
DDSet_Error: CFxInstaller::SetupComponents SetupScriptMaps failed. Error code: 0x80070422
You can use the following steps to work around this issue:
Issue 2: The IIS Admin Service is not installed
The .NET Framework 3.5 beta 2 will fail to install if setup is being run on a system that has parts of IIS installed, but does not have the IIS Admin Service installed.
DDSet_Error: CFxInstaller::SetupComponents SetupScriptMaps failed. Error code: 0x80070424
Issue 3: Insufficient privileges to modify application host config file
In some cases, the .NET Framework 3.5 beta 2 will fail to install if the user account that setup is running under does not have permission to modify IIS configuration files located at %windir%\system32\inetsrv\config.
This issue can cause one of the following entries to be written to the verbose MSI log file for the .NET Framework 3.5 component (named %temp%\dd_net_framework35_MSI*.txt):
DDSet_Error: CWebServerHandlers::Install m_spAppHostAdminManager->CommitChanges failed. Error code: 0x80070002 DDSet_Error: CWebServerHandlers::Install m_spAppHostAdminManager->CommitChanges failed. Error code: 0x80070005
DDSet_Error: CWebServerHandlers::Install m_spAppHostAdminManager->CommitChanges failed. Error code: 0x80070002
DDSet_Error: CWebServerHandlers::Install m_spAppHostAdminManager->CommitChanges failed. Error code: 0x80070005
We know of an issue with the NoImpersonate attribute not being set for this custom action that could cause this type of error, but have had trouble reproducing this issue in our test labs. In most cases, you can use the following steps to work around this issue:
If the above work around does not help, you can use the following steps as an alternative:
A refreshed version of the Windows Vista Media Center SDK (version 5.2) has been released for download. The download location is the same as the 5.0 and 5.1 versions - http://www.microsoft.com/downloads/details.aspx?FamilyID=A43EA0B7-B85F-4612-AA08-3BF128C5873E&displaylang=en. If you have the 5.0 or 5.1 version of the Windows Vista Media Center SDK installed, you can run the MSI for version 5.2 and it will automatically upgrade the older versions for you.
The features of this SDK refresh are described in more detail in this post on the Media Center Sandbox blog and also in the Getting Started page that appears at the end of SDK installation. The key changes are the following:
If you're a Windows Vista Media Center developer or thinking about getting started, I encourage you to download this new version of the SDK and check it out.
Description of this issue
Since Visual Studio 2008 beta 2 and the .NET Framework 3.5 beta 2 were released, we have heard of a few issues related to using ASP.NET controls in the VS IDE after installing beta 2. The issues we have seen so far include the following:
In the cases we've seen so far, the systems are running Windows Vista, and the file version of %windir%\Microsoft.NET\Framework\v2.0.50727\system.web.dll is less than the official beta 2 version of 2.0.50727.1378.
If you run into an issue like this, you can uninstall .NET Framework 2.0 hotfixes and then re-install the .NET Framework 3.5 as a workaround.
There are some detailed instructions that explain how to do this at this location, including a list of the exact hotfixes that need to be uninstalled to resolve this issue.
You do not need to re-install the previous hotfixes after working around this issue. The .NET Framework 2.0 SP1 and 3.0 SP1 hotfix packages that are installed as prerequisites for the .NET Framework 3.5 beta 2 already include all of the fixes that were previously released as separate Windows Vista hotfixes for the .NET Framework 2.0/3.0.
Root cause of this issue
We have found a problem with how some Windows Vista-specific hotfixes for the .NET Framework 2.0 have been packaged in the past that can cause an incorrect version of files like system.web.dll to appear on the system. This means that if you have some specific .NET Framework 2.0 hotfixes installed on your Windows Vista system, you might encounter this type of file version problem and therefore also run into some issues when trying to use VS 2008 beta 2. Windows Vista is built from components, and these components have their own version information that is used to determine which files will be present on the OS. The versions of the files contained in each of the components does not have to match the component version, and that can lead to newer versions of components having older versions of files in some cases such as this.
<update date="8/6/2007"> Added more details about the issues seen within the VS IDE to improve discoverability of this issue and possible workarounds </update>
A news item was recently posted on the MCEDev.com web site that I wanted to draw your attention to if you haven't seen it already. The post, located at http://www.mcedev.com/News.aspx?id=b88920c9-57a4-44fc-8feb-78c18b596fa8, announces a publicly downloadable beta of a Windows Vista Media Center application named TV Toolbox. This application is a new version of the Media Center Cutter application that has been available for a while for Windows XP Media Center Edition and that was previously announced with feature details and screenshots on Niall's Big Screen Blog back in March.
This application allows you to do things like the following from within Windows Media Center:
I encourage you to check out the following locations for more information about TV Toolbox:
Before installing Visual Studio 2008 beta 2 or the .NET Framework 3.5 beta 2, it is necessary to remove previous beta versions of VS 2008. In most cases, when running beta 2 setup on a system that has an earlier beta still installed, setup will block installation and display a dialog with a list of previous beta products that need to be uninstalled.
However, we discovered that there are a few previous beta products that are not being detected correctly. This means that if they are installed on the system, they will not be listed in the blocking dialog when running beta 2 setup.
If you have any of the following VS 2008 (formerly code named Orcas) editions installed on your system, make sure to remove them from Add/Remove Programs before installing VS 2008 beta 2:
Note that for all of the beta versions of VS 2008, including the products listed above, setup will automatically uninstall beta versions of prerequisites and optional components that were chained in during the beta uninstall process. This chaining was added in the VS 2008 products in order to help reduce problems we saw frequently during the VS 2005 beta program that were caused by uninstalling beta prerequisites out of order.
I previously posted a description of a bug in VS 2008 beta 1 and .NET Framework 3.5 beta 1 setup that can cause setup to prompt you to install Windows XP SP2 when running setup on Windows Vista. That post includes a couple of workarounds that can be used to remove the setting that Windows Vista stores that controls whether or not to run a program in Windows XP compatibility mode.
Why does this problem still happen in beta 2?
The underlying problem that caused this type of error to appear was that the beta 1 setup packages did not include embedded UAC manifests, which caused Windows Vista to treat them as legacy applications. The beta 2 setup packages now include the proper UAC manifests, so in most cases, this Windows XP SP2 prompt should no longer appear.
However, in cases where beta 1 setup previously failed on the same system, the registry setting could still exist and that may cause beta 2 setup to continue to run in Windows XP compatibility mode.
Workaround option 1 - manually clear application compatibility settings
If you see this type of error when running VS 2008 or .NET Framework 3.5 beta 2 setup, the first step I suggest is to try the workarounds listed at the bottom of this previous blog post (either changing the compatibility settings by right-clicking on the setup EXE and choosing the Compatibility tab, or manually removing entries from the registry).
Workaround option 2 - use the Program Compatibility Assistant
In a few cases I have seen, those workarounds did not cause the Windows XP SP2 error dialog to stop appearing on Windows Vista. If none of those other workarounds allow you to get past this issue, it may help to run the setup directly from within the Program Compatibility Assistant by using steps like the following:
Charlie recently posted a link on the Media Center Sandbox blog to an interesting case study on the Microsoft Case Studies web site that I wanted to also link to here. There is a new case study posted at http://www.microsoft.com/casestudies/casestudy.aspx?casestudyid=4000000490 that describes how Showtime and Method created the Showtime Interactive application for Windows Vista Media Center using the following technologies/tools:
If you have a Windows Vista Home Premium or Ultimate system, you can check out the Showtime Interactive application by launching Windows Media Center, going to the Online Media strip on the start menu, selecting Explore and then clicking on the Showtime Interactive link. This application is a locally installed program, so you will have to download and run the MSI-based installer prior to using the application.
If you're considering creating applications for Windows Vista Media Center, I encourage you to check out this case study for more information about how a real-world project project was designed and implemented.
I wrote a post yesterday with a list of the names and locations of all of the log files produced during Visual Studio 2008 and .NET Framework 3.5 setup. As you can see in that post, the list of possible log files is very long, and that makes it annoying when attempting to gather the logs and send them back to Microsoft so that we can help troubleshoot installation issues.
Fortunately, Sandhya, a colleague of mine, has written a tool that will automatically gather all of the VS 2008 and .NET Framework 3.5 setup log files it can find from your system and create a cab file containing them so you have a single compressed package that can be sent to Microsoft for troubleshooting purposes.
How to use the Collect tool
The tool can be downloaded from http://go.microsoft.com/?LinkId=8967043. It is a Win32 console application, so you can extract it from the zip file and double-click on it to run it. It will create a file named %temp%\vslogs.cab on your system after it has gathered all of the log files.
Note - after the tool finishes running, you can get to your %temp% folder to find the file vslogs.cab by clicking on the Start menu, choosing Run, typing %temp% and clicking OK.
What to do if the Collect tool does not work correctly on your system
If the tool encounters any problems, you can do the following to re-run it from a cmd prompt and see more detailed error information:
<update date="5/23/2008"> Updated link to log collection tool to point to the new location </update>