Problem Resolution: Installing Windows Phone 7 Developer Tools Beta

imageI ran into some issues installing the Windows Phone 7 developer tools beta this weekend on my PC. I had been cleaning up my hard drive of old installs so I likely had a bit of a mess. I had just installed a fresh copy of Expression Suite 4 Visual Studio 2010 Ultimate and the Silverlight 4 Tools. I tested those and everything worked great … so far so good.

Next step was to install the Windows Phone 7 developer tools beta. Here is where I ran into this problem …

“Setup has detected that this computer does not meet the requirements to install this software. These requirements must be met before you can install Microsoft Windows Phone Developer Tools Beta - ENU”

The incompatible product it was referring to is “Microsoft Visual Studio 2010 Express Prerequisites x64” as shown in the window below …

clip_image002

For those wanting the quick solution … it turns out that I had an old build of Visual Studio Express that I had to uninstall. But this message can appear for a variety of install blocking issues so I figured I would share what I learned about debugging the install issues.

Note: Aaron Stebner alerted me to a blog post he had written on debugging this and other messages. You can find that post here. The steps included below are my interpretation of Aaron’s steps in his “Issue #2” with specifics on my issue where applicable.

1) First, I opened the log file dd_install_vs_vstscore_100.txt for the install which is located in the %temp% folder. For me, this was located in this path:

C:\Users\John\AppData\Local\Temp\dd_install_vs_vstscore_100.txt

2) I opened the file in notepad and searched for “ERRORLOG EVENT” … you might as well search for ExecuteEachBlocker though. Either way, I found the section I needed that told me where to go next. Here is the section worth noting:

[08/13/10,23:32:15] VS Scenario: ***ERRORLOG EVENT*** : Error: CVSScenario::ExecuteEachBlocker returned false
[08/13/10,23:32:15] Setup.exe: AddGlobalCustomProperty
[08/13/10,23:32:15] VS Scenario: ***ERRORLOG EVENT*** : Error:There is a blocking condition met, the installer is blocking because of Section :
[08/13/10,23:32:15] Setup.exe: AddGlobalCustomProperty
[08/13/10,23:32:15] VS Scenario: ***ERRORLOG EVENT*** : Microsoft Visual Studio 2010 Express Prerequisites x64
[08/13/10,23:32:35] Setup.exe: AddGlobalCustomProperty
[08/13/10,23:32:35] VS Scenario: ***ERRORLOG EVENT*** : Failed to pass the Warnings/Blocks checks in CVSScenario::Start()

3) This is the match for the message in the error window so the next step is to find the key for this entry in the setup file. This can be found by going to the setup files for the WPDT beta setup data file named blocker.sdb which is located in the vm_web.exe self extracting package. (Aaron created an extracted copy at this location in case you want a quick link.) 

4) Once you open the file search for the offending key, which in my case was “Microsoft Visual Studio 2010 Express Prerequisites x64”. This finds a section such as the one below:

[Microsoft Visual Studio 2010 Express Prerequisites x64]
VersionCheck=RegVerBuildCheck
DetectKey=HKLM,SOFTWARE\Microsoft\DevDiv\vs\Servicing\10.0\expbsln
DetectKeyVal=Version
DetectKeyValData=30319.01
HelpLink=Block_on_Non_Dev10_RC_component_vm_exp.htm

5) This section identifies that if the key (DetectKey) is found and has a value (DetectKeyValData) less than the version listed, then a blocking issue will arise. This may be as far as you need to go.

6) If you cannot find this key it might be because the keys are slightly different for 64-bit versions of Windows. For clarity, the 32-bit key is …

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\DevDiv\vs\Servicing\10.0\expbsln

… and 64-bit is …

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\DevDiv\vs\Servicing\10.0\expbsln

7) My key had a value of 30128.01, so it was easy to see it was less than the required pre-req of 30319.0 that the message indicated.

image

 

Of course, when I went to the Control Panel to uninstall this blocking program it was pretty obvious in hindsight that it was the blocker. Notice the version in the image below is obviously older … reminds me of the old “which one of these is not like the other” saying :).

image

So in hindsight this issue could have been resolved quicker by a little more common sense on my part, but the steps were still very valuable in understanding the issue and might come in handy in the future.

Special thanks to Jaime Rodriguez and Aaron Stebner for their help with this.

Tweet Post Share Update RSS

Hi, I'm John Papa. I author this blog, create courses for Pluralsight and am a Google Developer Expert and Microsoft Regional Director. I travel speaking at events and train technology thought leaders

Tags:
Silverlight