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.
Because of some of the posts I’ve written in the past, I often get asked about how to install various products in silent or unattended mode. In some cases, I am familiar with the product and know how to answer the question. However, in a lot of cases, I don’t, and in those cases, I try running the installer with the /? command line switch to see if it will display a usage dialog to describe the available options. This technique doesn’t always help because some installers do not list any command line switches or they only list a selected subset of their supported switches. However, it has provided some very useful information in the past, and it is worth trying if you are having trouble finding documentation for setup command line switches.
For example, if you download the installer for the .NET Framework 4 and run it with the /? switch, you will see a lot of information about available command line switches. There are several standard options that are pretty well documented (silent/unattended install and uninstall), and there are several other useful options that you may not have been aware of:
As announced earlier today on the XNA Game Studio team blog and on the App Hub forums, there have been a few changes to the Xbox LIVE Indie Game submission policies to give developers more flexibility when submitting their games. Here is a brief summary of the changes:
Please visit this forum thread for more detailed information and answers to any questions you might have about these changes.
Every once in a while, I see a post on the App Hub forums (for example, here or here) where someone runs into an error related to the XNA Game Studio platform extensions add-in store when trying to open an XNA Game Studio project for Xbox 360 or Windows Phone. The error message looks like the following:
--------------------------- Microsoft XNA Game Studio --------------------------- The XNA Game Studio platform extensions add-in store returned the following error: Could not find the add-in deployment cache file, "C:\Program Files (x86)\Common Files\Microsoft Shared\XNA\PlatformExtensions\PipelineSegments.store". Please run AddInStore.Update or Rebuild (or run AddInUtil.exe on the command line). Also, ensure your code has permission to read this file. Please run Setup for Microsoft XNA Game Studio Platform Tools to repair your installation. --------------------------- OK ---------------------------
--------------------------- Microsoft XNA Game Studio --------------------------- The XNA Game Studio platform extensions add-in store returned the following error:
Could not find the add-in deployment cache file, "C:\Program Files (x86)\Common Files\Microsoft Shared\XNA\PlatformExtensions\PipelineSegments.store". Please run AddInStore.Update or Rebuild (or run AddInUtil.exe on the command line). Also, ensure your code has permission to read this file.
Please run Setup for Microsoft XNA Game Studio Platform Tools to repair your installation. --------------------------- OK ---------------------------
If you encounter an error like this while trying to use XNA Game Studio, there are a few different options that can be used to resolve it. I suggest trying them in the order listed below, and skip to the next option if the current option does not resolve the error for you.
Option 1 – re-install Microsoft XNA Game Studio Platform Tools
The XNA Game Studio Platform Tools is one of the sub-components that is installed behind the scenes by XNA Game Studio setup. You can re-install it by right-clicking on the platform tools MSI, choosing to uninstall it, then double-click on it and choose to install it. The platform tools MSI can be found at the following location on a computer that has XNA Game Studio 4.0 (or the 4.0 Refresh) installed.
On a 32-bit OS: %ProgramFiles%\Microsoft XNA\XNA Game Studio\v4.0\Setup\xnags_platform_tools.msi On a 64-bit OS: %ProgramFiles(x86)%\Microsoft XNA\XNA Game Studio\v4.0\Setup\xnags_platform_tools.msi
On a 32-bit OS:
On a 64-bit OS:
Option 2 – re-install Microsoft XNA Game Studio
For this option, you can go to the Programs and Features (or Add/Remove Programs) control panel and uninstall all of the following components:
Alternatively, you can use the XNA Game Studio cleanup tool.
After uninstalling the above components, re-download and re-install XNA Game Studio.
Option 3 – re-build the XNA Game Studio Platform Tools add-in store manually
If the above steps do not help, it might help to manually re-build the XNA Game Studio Platform Tools add-in store. These steps are run during Platform Tools setup, but in some cases they will fail, and running them manually can provide more useful error information for troubleshooting purposes.
Note – even though XNA Game Studio 4.0 (and the 4.0 Refresh) require VS 2010 and the .NET Framework 4, they will attempt to use the .NET Framework 3.5 to build the add-in store if the .NET Framework 3.5 is installed because platform tools components are shared by previous versions of XNA Game Studio (3.0 and 3.1), and older versions of XNA Game Studio cannot read the add-in store if it is re-built by the .NET Framework 4. Because of that, I recommend using the .NET Framework 3.5 to re-build the add-in store if you have it installed.
If you have the .NET Framework 3.5 installed, run the following commands from an elevated cmd prompt:
On a 32-bit OS: "%windir%\Microsoft.NET\Framework\v3.5\AddInUtil.exe" -PipelineRoot:"%ProgramFiles%\Common Files\microsoft shared\XNA\PipelineHosting\." -Rebuild "%windir%\Microsoft.NET\Framework\v3.5\AddInUtil.exe" -PipelineRoot:"%ProgramFiles%\Common Files\microsoft shared\XNA\PlatformExtensions\." -Rebuild On a 64-bit OS: "%windir%\Microsoft.NET\Framework\v3.5\AddInUtil.exe" -PipelineRoot:"%ProgramFiles(x86)%\Common Files\microsoft shared\XNA\PipelineHosting\." -Rebuild "%windir%\Microsoft.NET\Framework\v3.5\AddInUtil.exe" -PipelineRoot:"%ProgramFiles(x86)%\Common Files\microsoft shared\XNA\PlatformExtensions\." -Rebuild
If you do not have the .NET Framework 3.5 installed, but have the .NET Framework 4 installed, run the following commands from an elevated cmd prompt:
On a 32-bit OS: "%windir%\Microsoft.NET\Framework\v4.0.30319\AddInUtil.exe" -PipelineRoot:"%ProgramFiles%\Common Files\microsoft shared\XNA\PipelineHosting\." -Rebuild "%windir%\Microsoft.NET\Framework\v4.0.30319\AddInUtil.exe" -PipelineRoot:"%ProgramFiles%\Common Files\microsoft shared\XNA\PlatformExtensions\." -Rebuild On a 64-bit OS: "%windir%\Microsoft.NET\Framework\v4.0.30319\AddInUtil.exe" -PipelineRoot:"%ProgramFiles(x86)%\Common Files\microsoft shared\XNA\PipelineHosting\." -Rebuild "%windir%\Microsoft.NET\Framework\v4.0.30319\AddInUtil.exe" -PipelineRoot:"%ProgramFiles(x86)%\Common Files\microsoft shared\XNA\PlatformExtensions\." -Rebuild
Option 4 – re-install the .NET Framework
If the above options do not help, it might be necessary to repair/re-install the .NET Framework on your computer. As I described in the notes for option 3 above, the XNA Game Studio Platform Tools will use the .NET Framework 3.5 to build the add-in store if the .NET Framework 3.5 is installed on the computer. As a result, you will need to try to repair/re-install both the .NET Framework 3.5 and the .NET Framework 4.
Option 5 – if none of the above help
If none of the above options solve this error, please do the following:
The 2012 Dream.Build.Play competition was introduced yesterday in a post on the XNA Game Studio team blog. The 2012 competition will be open to both Xbox 360 and Windows Phone games. Here are a couple of links with additional information:
There is a new general-purpose installation troubleshooting tool called the Program Install and Uninstall Troubleshooting Tool that has been available on the Microsoft support site for a little while, and I want to post some information about this tool to help make it easier for people to find it.
This tool is conceptually similar to the .NET Framework cleanup tool, but it is more generic and can be used to clean up any MSI-based installation on a computer. It also performs more robust back-up steps prior to cleaning up in case you need to roll back to a previous state.
Where to download the Program Install and Uninstall Troubleshooting Tool
You can find more information about the Program Install and Uninstall Troubleshooting Tool and download it from the following locations:
Summary information about the tool
The Program Install and Uninstall Troubleshooting Tool can be used to automatically diagnose problems that can prevent installing and uninstalling programs on your computer. It can help resolve some errors that prevent programs from uninstalling, installing or updating correctly. Here is a list of issues that this tool is currently able to fix:
This tool is designed as a last resort for cases where install, uninstall, repair or patch installation did not succeed for unusual reasons. It is not a substitute for the standard uninstall procedure. You should use only use this tool to uninstall a program if the program fails to uninstall using the entry in the Programs and Features control panel.
More details about how the tool works
The Program Install and Uninstall Troubleshooting Tool does the following behind the scenes when you use it to uninstall a program:
The Program Install and Uninstall Troubleshooting Tool requires Windows Installer product codes in order to know what file and registry information to remove from the computer. For programs that are listed in the tool UI, the product code will appear as a tool tip when you mouse over the product name. If you choose the Not Listed option in the tool UI, you can use a tool like MsiInv to determine the product code.
If you use the Windows Phone SDK 7.1, it is possible to get an error like the following when building a Silverlight project:
The target "GetCopyToOutputDirectoryContentProjectItems" does not exist in the project.
How to resolve this issue
In the cases that I’ve seen this error in the past, it was caused by XNA Game Studio 4.0 not being correctly installed on the computer. If you encounter this error, I suggest trying one of the following:
More details about the root cause of the issue
The GetCopyToOutputDirectoryContentProjectItems target is defined in an MSBuild .targets file installed by XNA Game Studio 4.0. In the Windows Phone SDK 7.1, one of the Silverlight .targets files has a dependency on this XNA Game Studio 4.0 build target in order to support building the new combined Silverlight and XNA applications. This dependency exists for standard Silverlight projects in addition to Silverlight and XNA application projects. As a result, it is possible to get into a state where you cannot build a Silverlight project in the Windows Phone SDK 7.1 when XNA Game Studio 4.0 is not installed even if you are not using XNA Game Studio features in your Silverlight project.
I have seen several people ask about this scenario on the App Hub forums, and I wanted to write a blog post to help raise visibility because it is hard to find in the release notes.
Description of the issue
The Windows Phone SDK 7.1 introduces the ability to create applications that combine Silverlight and XNA Framework technologies. If you create a new Windows Phone Silverlight and XNA Application using the project template that ships with the Windows Phone SDK 7.1, you will see a warning like the following in the Visual Studio error window:
The project 'SlXnaApp1Lib' cannot be referenced. The referenced project is targeted to a different framework family (.NETFramework)
This warning will not prevent you from building or running the Silverlight and XNA Application project, and you can safely ignore the warning.
A Silverlight and XNA Application includes a Silverlight project, an XNA Game Studio Windows Phone Game Library project and an XNA Game Studio content project. The Silverlight project is the parent project, and it includes a project-to-project reference to the XNA game library project. The warning occurs because Visual Studio detects that the XNA project does not target the same .NET Framework profile as the Silverlight project. However, on Windows Phone, there is only one .NET Framework profile, regardless of what the target framework settings are in the project files, so the warning does not indicate any possible functional problems when you build and run your application.
Rob Mensching posted an item on his blog announcing the release of the WiX v3.6 beta. The key feature in WiX v3.6 is the Burn bootstrapper/chainer. To summarize Rob’s post, Burn includes the following features:
In addition, all known WiX core toolset bugs that were opened against WiX v3.5 or earlier have been fixed in the WiX v3.6 beta.
I encourage you to download the WiX v3.6 beta and give it a try if you get a chance.
Last week, we released the final version of the Windows Phone SDK 7.1, which includes the final version of the XNA Game Studio 4.0 Refresh. After a bit of a delay, we have now also released the standalone versions of the XNA Game Studio 4.0 Refresh and the XNA Framework 4.0 Refresh so you can download and install them separately if you plan to develop Windows and/or Xbox 360 games with XNA Game Studio but do not want to install the full Windows Phone SDK 7.1 in order to do so.
Here are the standalone download links:
XNA Game Studio 4.0 Refresh
XNA Framework Redistributable 4.0 Refresh
If you have the original version of XNA Game Studio 4.0 or the XNA Framework Redistributable 4.0 installed on your computer, the Refresh installers will automatically upgrade them for you behind the scenes. If you have any beta version of the Windows Phone SDK 7.1 installed, the Refresh installers will not automatically upgrade them, and you will need to uninstall the beta version first.
If you encounter XNA Game Studio setup failures
If you run into an installation or uninstallation failure for XNA Game Studio, please zip your setup log files, upload them to a file server of your choice (such as http://skydrive.live.com), and post a link to the log files in the App Hub Forums or in a comment on my blog to get additional support. Here are the log file locations for each version of XNA Game Studio:
If you run into uninstallation issues with any release of the Windows Phone SDK or XNA Game Studio, you can use the cleanup tool described at http://blogs.msdn.com/astebner/pages/9544320.aspx to forcibly remove the Windows Phone SDK or XNA Game Studio.
Note: This is an updated version of a previous mailbag entry that I posted before the .NET Framework 4 shipped.
Question:
I recently installed the .NET Framework 4 on my system. Afterwards, I looked in Add/Remove Programs, and it shows that I have all of the following versions of the .NET Framework installed on my system:
Do I need any of these older versions of the .NET Framework now that I’ve installed the .NET Framework 4, or can I safely uninstall them?
Answer:
In general, my recommendation is to leave the .NET Framework 2.0 SP2, 3.0 SP2, 3.5 SP1 and 4 installed on your computer.
Unlike previous versions of the .NET Framework, the .NET Framework 4 does not allow an application that was built with previous versions of the .NET Framework to migrate forward and run on it if the previous version is not installed. If you are using any applications that were built with any version of the .NET Framework before version 4, then I recommend leaving both the .NET Framework 3.5 SP1 and the .NET Framework 4 installed.
You cannot use the .NET Framework 3.5 SP1 unless you also have the .NET Framework 2.0 SP2 and 3.0 SP2 installed. Therefore, you will not be allowed to uninstall the .NET Framework 2.0 SP2 or 3.0 SP2 if you have the .NET Framework 3.5 SP1 installed. If you try to uninstall the .NET Framework 2.0 or 3.0 when the .NET Framework 3.5 is installed, their uninstall processes will block and tell you that they are needed by another application on your system.
The .NET Framework 1.0 and .NET Framework 1.1 can be installed side-by-side with the .NET Framework 2.0, 3.0, 3.5 and 4. Most applications that were created for the .NET Framework 1.0 or 1.1 will automatically use the .NET Framework 2.0 instead if it is installed on the system. In most cases, that means you do not need to keep the .NET Framework 1.0 or 1.1 installed on your system if you already have the .NET Framework 2.0 installed.
However, there are some applications that are configured to require a specific version of the .NET Framework, even if later versions of the .NET Framework are installed. If you have any applications like that on your system and try to run them without installing the .NET Framework 1.0 or 1.1, you will get an error message that looks like the following:
--------------------------- MyApplication.exe - .NET Framework Initialization Error --------------------------- To run this application, you first must install one of the following versions of the .NET Framework: v1.1.4322 Contact your application publisher for instructions about obtaining the appropriate version of the .NET Framework. --------------------------- OK ---------------------------
In the above error message, the version number will be v1.0.3705 if you need to install the .NET Framework 1.0, and it will be v1.1.4322 if you need to install the .NET Framework 1.1.
If you end up seeing any error messages like this, you can re-install the .NET Framework 1.0 or 1.1 in order to resolve the errors. If you don't end up seeing any error messages like this, then you don't need to worry about re-installing the .NET Framework 1.0 or 1.1.
As announced on the Windows Phone Developer Blog and on the App Hub web site, the final version of the Windows Phone SDK 7.1 (formerly named the Windows Phone Developer Tools, and which includes the XNA Game Studio 4.0 Refresh as well) was released for download today.
Getting Started links
Here are links to help you get started installing and using the English version of the Windows Phone SDK 7.1:
Here are download links for non-English versions of the Windows Phone SDK 7.1:
Documentation links
Here are some links to documentation to help you get started using the Windows Phone SDK 7.1:
Support links
Here are some links if you run into questions or issues with the Windows Phone SDK 7.1:
How to install
Here are steps you can use to install the Windows Phone SDK 7.1:
If you encounter Windows Phone SDK 7.1 setup failures
If you run into an installation or uninstallation failure for the Windows Phone SDK 7.1, you can use the log collection tool to gather your setup log files. This log collection tool will create a file named %temp%\vslogs.cab.
Once you have gathered your setup log files, you can upload them to a file server of your choice (such as http://skydrive.live.com), and post a link to the log files in the forums to get additional support.
If you run into uninstallation issues with any release of the Windows Phone SDK or XNA Game Studio, you can use the cleanup tool described at http://blogs.msdn.com/astebner/pages/9544320.aspx to remove the Windows Phone SDK or XNA Game Studio.
As announced on the Building Windows 8 blog and on Jason Zander’s blog among other places, a developer preview of Windows 8 is available for download. One of the download options for the Windows 8 Developer Preview includes a pre-installed version of the developer tools, including Visual Studio 11 and .NET Framework 4.5 developer preview.
Here are some links to help you get started downloading and using the Windows 8 Developer Preview and the associated developer tools:
Rob Mensching posted some additional information on his blog about setup features in Visual Studio 11. There are a couple of key points that he mentioned in his post that I want to highlight here as well:
I recently received a .NET Framework update from Windows Update. It installed successfully, but Windows Update continues to offer this update to my computer afterwards. How can I get Windows Update to detect that this update is correctly installed on my computer?
In some cases, Windows Update can get confused and think that it needs to continue to offer an update to a computer even after it has been successfully installed. In this type of scenario, it can sometimes help to reboot your computer and then use the steps listed at http://support.microsoft.com/kb/971058 to reset the Windows Update components on your computer.
If Windows Update continues to offer an update to your computer even after resetting Windows Update components, then you might need to uninstall and re-install the product that the update applies to in order to cause Windows Update to correctly detect the installation state of the update.
As announced on the Windows Phone Developer Blog and on the App Hub web site, the Windows Phone SDK 7.1 Release Candidate (RC) (formerly named the Windows Phone Developer Tools, and which includes the XNA Game Studio 4.0 Refresh RC as well) was released for download earlier this week.
The Windows Phone SDK 7.1 RC includes the following changes from the Windows Phone SDK 7.1 Beta 2 release:
Here are links to help you get started installing and using the Windows Phone SDK 7.1 RC:
Here are some links to useful documentation to help you get started with the Windows Phone SDK 7.1 RC:
Here are some links if you run into questions or issues with the Windows Phone SDK 7.1 RC:
Here are steps you can use to install the Windows Phone SDK 7.1 RC:
If you encounter Windows Phone SDK 7.1 Beta 2 setup failures
If you run into an installation or uninstallation failure for the Windows Phone SDK 7.1 RC, you can use the log collection tool to gather your setup log files. This log collection tool will create a file named %temp%\vslogs.cab.
The Windows Phone SDK 7.1 includes a step to install the XNA Game Studio 4.0 Refresh. Behind the scenes, the XNA Game Studio 4.0 Refresh installer has logic to detect if the computer has the original version of XNA Game Studio 4.0 installed. If so, the XNA Game Studio 4.0 Refresh installer will automatically uninstall XNA Game Studio 4.0 because the refresh is a super-set of the original version and there is no need to have both installed at the same time.
However, there is an installation ordering issue that can end up causing problems. The original XNA Game Studio 4.0 installer does not have any knowledge about the refresh, so if you run the installer for the original version of XNA Game Studio 4.0 on a computer that already has the XNA Game Studio 4.0 Refresh installed, setup will run in repair mode and it will let you attempt to “repair” XNA Game Studio 4.0. If you do this, you will end up with a mixed and matched set of components from the original version of XNA Game Studio 4.0 and the XNA Game Studio 4.0 Refresh. Once a computer gets into this state, attempting to uninstall either one of the versions of XNA Game Studio will only partially remove it because some of the components are shared by both versions.
If you accidentally install the original version of XNA Game Studio 4.0 onto a computer that already has the XNA Game Studio 4.0 Refresh, here are some steps that will allow you to clean things up and get back to a consistent set of XNA Game Studio 4.0 components:
If you try the above steps and run into any installation problems, please go to %temp%\XNA Game Studio 4.0 Setup\Logs, zip all of your setup log files, upload the zip file to a file server (such as http://skydrive.live.com), and then post a comment on this blog post that includes a link that I can use to download your log files and take a closer look.
A while back, I wrote a blog post explaining how to localize the title of a Windows Phone game. That blog post includes a link to the Windows Phone 7 Title Localizer tool that can be used to quickly create native resource DLLs with localized versions of the game’s title. A couple of days ago, the creator of this tool released an update so it can now be used to create native resource DLLs for the new Windows Phone Mango languages.
You can find more information about the tool at http://patrickgetzmann.wordpress.com/wp7-localize/. You can find a list of steps to localize the title of your Windows Phone game using this tool in this blog post.
The Windows Phone SDK 7.1 Beta 2 that was released last week includes the XNA Game Studio 4.0 Refresh Beta 2. There is a change that we made in the XNA Game Studio 4.0 Refresh between Beta 1 and Beta 2 that I want to highlight because it hasn’t been advertised up to this point.
Shawn Hargreaves made a change to the content pipeline build process to address a long-standing pain point. On certain OS configurations, it is now possible to build content via the content pipeline without requiring the ability to create a D3D device. This means that starting in the XNA Game Studio 4.0 Refresh Beta 2, you can build content in the following types of configurations:
This functionality depends on a D3D API that does not exist on all versions of Windows that are supported by the XNA Game Studio 4.0 Refresh. Specifically, this functionality is only available on Windows Vista and later. On Windows XP, the content pipeline will continue to behave the way it has in the past, and it will require the ability to create a D3D device at content build time.
Assuming you are building your game on a supported OS, this functionality will work equally well for Windows, Xbox 360 and Windows Phone games.
If you have a build system for your XNA Game Studio game and are looking for more flexibility for your build machine configurations, I encourage you to try out the updated content pipeline build process in the XNA Game Studio 4.0 Refresh. If you do so, please go to the App Hub forums and let us know if you have any questions or run into any problems.
As announced on the Windows Phone Developer Blog and on the App Hub web site, the Windows Phone SDK 7.1 Beta 2 (formerly named the Windows Phone Developer Tools, and which includes the XNA Game Studio 4.0 Refresh Beta 2 as well) was released for download earlier this week.
The Windows Phone SDK 7.1 Beta 2 includes the following changes from the original Windows Phone Developer Tools 7.1 Beta release:
Here are links to help you get started installing and using the Windows Phone SDK 7.1 Beta 2:
Here are some links to useful documentation to help you get started with the Windows Phone SDK 7.1 Beta 2:
Here are some links if you run into questions or issues with the Windows Phone SDK 7.1 Beta 2:
Here are steps you can use to install the Windows Phone SDK 7.1 Beta 2:
If you run into an installation or uninstallation failure for the Windows Phone SDK 7.1 Beta 2, you can use the log collection tool to gather your setup log files. This log collection tool will create a file named %temp%\vslogs.cab.
If you run into uninstallation issues with any release of the Windows Phone Developer Tools or XNA Game Studio, you can use the cleanup tool described at http://blogs.msdn.com/astebner/pages/9544320.aspx to remove the Windows Phone SDK or XNA Game Studio.
<update date="7/5/2011"> Added a link to download the Windows Phone SDK 7.1 Beta 2 ISO image. </update>
The Windows Phone Developer Tools 7.1 allows you to create applications and games that target both Windows Phone OS 7.0 and Windows Phone OS 7.1. In some cases, you may want to create separate versions of an application or game that target both versions of the Windows Phone OS and that share common code. There is not a way to automatically create a Visual Studio solution and projects to do that. Here are some manual steps you can use to create XNA Game Studio 4.0 projects that target Windows Phone 7.0 and 7.1 and that share code and content:
You can find a sample solution that I created that I have already completed all of the above steps for at http://cid-27e6a35d1a492af7.skydrive.live.com/self.aspx/Blog_Tools/WPGameMultiTargetingSample.zip.
The above steps will create a solution and a set of projects that behave differently than a traditional multi-platform solution in XNA Game Studio that is created by starting a project for one platform and then creating a copy of it for another platform via the Create Copy of Project menu item in the Visual Studio IDE. Projects created with Create Copy of Project will be automatically synchronized behind the scenes so that if you add, remove or rename a file in one project, it is reflected in the other copies. After completing the above steps, you will need to make sure that you manually synchronize any file add, remove or rename operations. Changing code within files that have already been added to both projects will be picked up when you build either one of the projects though.
The Windows Phone Developer Tools 7.1 allows you to create and develop applications and games that target both Windows Phone OS 7.0 and Windows Phone OS 7.1. The Visual Studio project file for an application or game can only target one version of the Windows Phone OS. You can upgrade a project that targets 7.0 to target 7.1 in the Visual Studio UI, but once you upgrade, you cannot downgrade it from the Visual Studio UI. Because of that, the upgrade UI recommends making a backup of your 7.0 project before proceeding with the upgrade process.
If you have an XNA Game Studio Windows Phone 7.0 game project that you have upgraded to 7.1 and you didn’t make a backup copy before the upgrade, you can use the following steps to manually downgrade it to 7.0:
As noted in my previous blog post, the Windows Phone Developer Tools 7.1 Beta was released this week. I’ve heard from a few people who have had problems installing the WPDT 7.1 beta because setup detected incompatible components installed on the computer. I want to describe this scenario in a bit more detail in case anyone reading my blog in the future runs into similar problems.
If you see an error installing WPDT 7.1 due to incompatible components, I suggest using steps like the following to diagnose and resolve this issue:
[Microsoft Visual C# Express 2010] VersionCheck=PreReqRegVerCheck DetectKey=HKLM,SOFTWARE\Microsoft\DevDiv\vcs\Servicing\10.0\xcor DetectKeyVal=Version DetectKeyValData=40219.01 This means that setup will block if the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\DevDiv\vcs\Servicing\10.0\xcor@Version exists and the value is less than 40219.01. There is one subtle issue here - the WPDT setup is a 32-bit application, so that means that the registry location will be different on a 64-bit version of Windows. In the example above, the registry key will be at HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\DevDiv\vcs\Servicing\10.0\xcor@Version.
If you run into WPDT installation issues that are not solved by the above suggestion, you can use the log collection tool to gather your setup log files. This log collection tool will create a file named %temp%\vslogs.cab. Once you have gathered your setup log files, you can upload them to a file server of your choice (such as http://skydrive.live.com), and post a link to the log files in the forums or in a comment on my blog to get additional support.
<update date="8/29/2011"> Added a step to restart the computer in case there are any files or registry keys in use that need to be removed by the uninstall process in step 3. </update>
As announced on the Windows Phone Developer Blog and on the App Hub web site, the Windows Phone Developer Tools (WPDT) 7.1 Beta (which includes an XNA Game Studio 4.0 Refresh Beta as well) was released for download today.
Here are links to help you get started installing and using the Windows Phone Developer Tools Beta:
Here are some links to useful documentation to help you get started with the Windows Phone Developer Tools Beta:
Here are some links to useful documentation to help you get started with the XNA Game Studio 4.0 Refresh beta:
Here are some links if you run into questions or issues with the Windows Phone Developer Tools 7.1 Beta:
Here are steps you can use to install the Windows Phone Developer Tools 7.1 Beta:
If you encounter Windows Phone Developer Tools 7.1 Beta setup failures
If you run into an installation or uninstallation failure for the Windows Phone Developer Tools 7.1 Beta, you can use the log collection tool to gather your setup log files. This log collection tool will create a file named %temp%\vslogs.cab.
If you run into uninstallation issues with any release of the Windows Phone Developer Tools or XNA Game Studio, you can use the cleanup tool described at http://blogs.msdn.com/astebner/pages/9544320.aspx to remove WPDT or XNA Game Studio.
I have heard from a few people in the past who have run into setup failures with error code 1719 or 1723 while installing the 64-bit version of the .NET Framework on a 64-bit version of Windows. I want to describe the underlying issue in a little more detail and provide a couple of possible workarounds in case you run into this type of issue in the future.
How to diagnose this issue
If you are encountering this issue, you will see one of the following errors in the verbose MSI log file for the failing installation:
MSI (s) (DC:FC) [12:34:56:023]: Invoking remote custom action. DLL: C:\Windows\Installer\MSICE44.tmp, Entrypoint: SchedSecureObjects MSI (s) (DC:B8) [12:34:56:024]: Generating random cookie. MSI (s) (DC:B8) [12:34:56:051]: Created Custom Action Server with PID 1884 (0x75C). MSI (s) (DC:98) [12:34:56:092]: Running as a service. MSI (s) (DC:98) [12:34:56:094]: Custom Action Server rejected - Wrong Context MSI (s) (DC:B8) [12:34:56:097]: CA Server Process has terminated. Action start 12:34:56: SchedSecureObjects_x64. MSI (s) (DC:94) [12:34:56:098]: Note: 1: 1719 CustomAction SchedSecureObjects_x64 returned actual error code 1601 (note this may not be 100% accurate if translation happened inside sandbox) MSI (s) (DC:94) [12:34:56:738]: Product: Microsoft .NET Framework 4 Client Profile -- Error 1719. The Windows Installer Service could not be accessed. This can occur if the Windows Installer is not correctly installed. Contact your support personnel for assistance. MSI (s) (B4:74) [12:34:56:098]: Note: 1: 1723 CustomAction SchedSecureObjects_x64 returned actual error code 1157 (note this may not be 100% accurate if translation happened inside sandbox) MSI (s) (B4:74) [12:34:56:738]: Product: Microsoft .NET Framework 4 Client Profile -- Error 1723. There is a problem with this Windows Installer package. A DLL required for this install to complete could not be run. Contact your support personnel or package vendor. Action SchedSecureObjects_x64, entry: SchedSecureObjects, library: C:\Windows\Installer\MSIE8C8.tmp
MSI (s) (DC:FC) [12:34:56:023]: Invoking remote custom action. DLL: C:\Windows\Installer\MSICE44.tmp, Entrypoint: SchedSecureObjects MSI (s) (DC:B8) [12:34:56:024]: Generating random cookie. MSI (s) (DC:B8) [12:34:56:051]: Created Custom Action Server with PID 1884 (0x75C). MSI (s) (DC:98) [12:34:56:092]: Running as a service. MSI (s) (DC:98) [12:34:56:094]: Custom Action Server rejected - Wrong Context MSI (s) (DC:B8) [12:34:56:097]: CA Server Process has terminated. Action start 12:34:56: SchedSecureObjects_x64. MSI (s) (DC:94) [12:34:56:098]: Note: 1: 1719 CustomAction SchedSecureObjects_x64 returned actual error code 1601 (note this may not be 100% accurate if translation happened inside sandbox) MSI (s) (DC:94) [12:34:56:738]: Product: Microsoft .NET Framework 4 Client Profile -- Error 1719. The Windows Installer Service could not be accessed. This can occur if the Windows Installer is not correctly installed. Contact your support personnel for assistance.
MSI (s) (B4:74) [12:34:56:098]: Note: 1: 1723 CustomAction SchedSecureObjects_x64 returned actual error code 1157 (note this may not be 100% accurate if translation happened inside sandbox) MSI (s) (B4:74) [12:34:56:738]: Product: Microsoft .NET Framework 4 Client Profile -- Error 1723. There is a problem with this Windows Installer package. A DLL required for this install to complete could not be run. Contact your support personnel or package vendor. Action SchedSecureObjects_x64, entry: SchedSecureObjects, library: C:\Windows\Installer\MSIE8C8.tmp
The underlying problem in this scenario is that Windows Installer is incorrectly configured to run in 32-bit mode. 64-bit custom actions cannot run in 32-bit mode, and so any 64-bit MSI that includes a 64-bit custom action (including, but not limited to, all 64-bit versions of the .NET Framework starting with 2.0) will fail in this way the first time it tries to run a 64-bit custom action.
How to work around this issue
If you are encountering this issue, you can remove the following registry value to prevent Windows Installer from trying to run 64-bit custom actions in 32-bit mode:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\msiserver] WOW64=1
If the above registry value does not exist on your computer, then there is another possible root cause and workaround described in this blog post from Robert Flaming.
Last fall, I wrote a blog post linking to some information about using Guide.IsTrialMode in an XNA Game Studio 4.0 game for Windows Phone. Since then, the XNA Game Studio team has updated the behavior of the Guide.IsTrialMode API to simulate the same performance characteristics during development that a game will experience when a game is downloaded from the Windows Phone Marketplace. This change is available in the Windows Phone update that was released this spring:
As a result of this behavior change, the following point in my previous blog post no longer applies:
The following points from my previous blog post still apply, and should be taken into account when implementing trial mode functionality in your game:
<update date="5/5/2011"> Added a clarifying note to recommend that the trial check be done in the Activated event handler. </update>
A while back, I wrote a blog post explaining how to install offline documentation for the Windows Phone Developer Tools. Up until recently, those steps worked for the Windows Phone Development documentation, but not the XNA Game Studio 4.0 documentation. It has taken a little while, but the XNA Game Studio 4.0 documentation can now be downloaded for offline viewing using these steps as well. This will allow you to access help by pressing F1 within Visual Studio during XNA Game Studio development even if you are working offline.