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:

1. Open the file %temp%\dd_install_vm_xcor2_100.txt and determine the exact components that WPDT setup has identified as incompatible.  The incompatible products will generate log file entries like the following:
   
   [05/27/11,10:49:40] VS Scenario: ***ERRORLOG EVENT*** : Error: CVSScenario::ExecuteEachBlocker returned false
   [05/27/11,10:49:40] Setup.exe: AddGlobalCustomProperty
   [05/27/11,10:49:40] VS Scenario: ***ERRORLOG EVENT*** : Error:There is a blocking condition met, the installer is blocking because of Section :
   [05/27/11,10:49:40] Setup.exe: AddGlobalCustomProperty
   [05/27/11,10:49:40] VS Scenario: ***ERRORLOG EVENT*** : Microsoft Visual C# Express 2010
   
   
2. Look in the WPDT setup data file named blocker.sdb to determine the exact registry key that is being used to detect each incompatible product.  Blocker.sdb is located in the vm_web.exe self-extracting setup package, and I have posted an extracted copy at this location.  For the product in the above example, the information in blocker.sdb looks like the following:

   [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.

3. Use the Programs and Features control panel to uninstall the product that is triggering the block.
   
   
4. Restart the computer.
   
   
5. In some cases, uninstalling the product will not remove the registry key that WPDT setup is checking for in blocker.sdb.  In those cases, you may have to manually rename or delete the registry value so that the block will no longer be triggered.

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.

Getting Started links

Here are links to help you get started installing and using the Windows Phone Developer Tools Beta:

• Windows Phone Developer Tools 7.1 Beta download page
• Windows Phone Developer Tools 7.1 Beta release notes

Documentation links

Here are some links to useful documentation to help you get started with the Windows Phone Developer Tools Beta:

• What’s new in the WPDT 7.1 Beta
• What’s new for games in the WPDT 7.1 Beta
• Windows Phone developer documentation home
• Windows Phone OS 7.1 code samples

Here are some links to useful documentation to help you get started with the XNA Game Studio 4.0 Refresh beta:

• XNA Game Studio 4.0 Refresh developer documentation home
• List of new game development articles and samples
• App Hub getting started page
• App Hub game developer education home

Support links

Here are some links if you run into questions or issues with the Windows Phone Developer Tools 7.1 Beta:

• App Hub forums
• Connect site for reporting Windows Phone Developer Tools bugs and suggestions
• Connect site for reporting Expression Blend bugs and suggestions
• Connect site for reporting XNA Game Studio bugs and suggestions

How to install

Here are steps you can use to install the Windows Phone Developer Tools 7.1 Beta:

1. If you have any Visual Studio 2010 editions (such as Professional, Ultimate, C# Express, etc) installed on your computer, you will need to install Visual Studio 2010 SP1 first.
2. If you have the original Windows Phone 7 version of WPDT and/or XNA Game Studio 4.0 installed, you do not need to uninstall them.  The WPDT 7.1 Beta and the XNA Game Studio 4.0 Refresh Beta will automatically uninstall the previous version for you behind the scenes.
3. After updating any existing editions of VS 2010 to SP1, you can proceed with installing the WPDT 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.

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 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

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:

• The emulator image with the updated behavior is a part of the Windows Phone Developer Tools January 2011 Update.
• The updated behavior is delivered to phones via the update code-named “NoDo” that has been rolling out this spring.

As a result of this behavior change, the following point in my previous blog post no longer applies:

• This performance problem only manifests itself when a game is downloaded from the Windows Phone Marketplace – you will not see it when running your game in the emulator or when using Guide.SimulateTrialMode on a device during development.

The following points from my previous blog post still apply, and should be taken into account when implementing trial mode functionality in your game:

• On Windows Phone, calling Guide.IsTrialMode can be expensive (~60 milliseconds per call), so it should not be called every frame in your game code.
• This performance problem does not occur on Xbox 360, so pay particular attention to how you are using Guide.IsTrialMode if you are porting a game from the Xbox 360 to Windows Phone.
• You should consider checking the trial mode state at startup (specifically, in your Activated event handler) and at key intervals during your game instead of every frame.  For example, if you have a functionality-limited trial mode, you could check the state at the end of the last level that is a part of your trial experience and determine whether or not to unlock subsequent levels.

<update date="5/5/2011"> Added a clarifying note to recommend that the trial check be done in the Activated event handler. </update>