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.
A customer on the App Hub forums ran into an issue that I wanted to describe in more detail here in case anyone else runs into it in the future. If you have a Windows game project created with XNA Game Studio 3.0 or 3.1 and upgrade it to XNA Game Studio 4.0, ClickOnce publishing will not work correctly. This happens because the prerequisites for the game still include the older versions of the .NET Framework and the XNA Framework Redistributable that were needed by XNA Game Studio 3.0 or 3.1.
If you have upgraded a Windows game from XNA Game Studio 3.0 or 3.1 to 4.0 and want to be able to use the publish command to create a ClickOnce installer for it, you can use the following workaround:
A couple of weeks ago, I got the opportunity to meet and chat with several XNA and DirectX MVPs at the 2011 MVP Summit on the main Microsoft campus in Redmond, Washington. At the summit, a couple of the MVPs, Chris Williams and George Clingerman, were autographing copies of their new book, Professional Windows Phone 7 Game Development – Creating Games Using XNA Game Studio 4.
The book was released in February 2011, and it provides in-depth information about developing and publishing Windows Phone 7 games using XNA Game Studio 4.0, including 3 complete games. If you are looking into developing games using XNA Game Studio and the Windows Phone 7 platform, I encourage you to check out this book. You can find it on Amazon.com and at other retailers.
Question:
I have a Windows Phone project that was created by somebody else, and when I double-click on the .sln file, it opens in Visual Studio 2010 Express for Windows Phone. I have Visual Studio 2010 Professional installed and would prefer to use that for my Windows Phone development scenarios. How can I force Windows Phone .sln file to open in Visual Studio 2010 Professional instead of Visual Studio 2010 Express for Windows Phone?
Answer:
In your scenario, the .sln was originally created in the Visual Studio 2010 Express for Windows Phone edition. The general philosophy used by Visual Studio is to try to open a .sln in the exact edition that it was originally created in, and then to fall back to other supported Visual Studio editions in the same product family if that exact edition is not installed.
There are a few options you can use to cause a Windows Phone .sln file to open in Visual Studio 2010 Professional by default.
Option 1 – Update the metadata in the .sln file
You can open the .sln file in a text editor such as Notepad and change the following value at the top of the file:
# Visual Studio 2010 Express for Windows Phone
To cause the .sln to open in Visual Studio 2010 Professional by default, change the above line to the following:
# Visual Studio 2010
After you change that value and save and close your .sln file, double-clicking on the .sln will cause it to attempt to be opened in Visual Studio 2010 Professional (or Premium or Ultimate) if that edition is installed on your computer. It will still fall back to trying the express edition if Visual Studio 2010 Professional is not installed.
Note – when using this option, you will have to change the metadata in every .sln file that you want to change the default behavior for.
Option 2 – Update the default verb handler for the .sln extension
You can right-click on a .sln, choose Open With, then Choose Default Program. It is usually set to the Microsoft Visual Studio Version Selector by default. You can browse to the Visual Studio 2010 version of devenv.exe and force the computer to open .sln files with Visual Studio 2010 Professional instead of the version selector.
This option will change the behavior for all .sln files opened on the computer, including .sln files created in other Visual Studio product families (such as Visual Studio 2005 or 2008). This option typically does not work well if you have multiple Visual Studio editions from different product families installed side-by-side and you regularly use .sln files from multiple Visual Studio product families on the same computer.
Option 3 – Rename the vpdexpress.exe program
You can rename the Visual Studio 2010 Express for Windows Phone executable (vpdexpress.exe), and this will cause the Visual Studio version selector to think that the express edition is not installed. That will cause the .sln to open in Visual Studio 2010 Professional even if the metadata in the .sln file says that the .sln file was created with the express edition.
This option is the most invasive, but allows you to avoid needing to update each .sln file, and it does not affect the ability to open .sln files created with other Visual Studio product families.
Recently, we have run into a few issues where XNA Game Studio 4.0 Windows Phone games did not display proper localized strings when changing the phone OS language. We narrowed down these issues to problems in the game .csproj file that ended up preventing localized resource DLLs from being correctly packaged into the XAP file and deployed to the phone. These issues are pretty subtle and easy to miss, so I wanted to describe them in a bit more detail in case anyone else runs into these issues in the future.
Note – the issues in this post are specific to XNA Game Studio projects for Windows Phone. Localized resource DLLs will be correctly packaged in Silverlight projects for Windows Phone regardless of the format that you use for the <SupportedCultures> tag.
Issue 1 – <SupportedCultures> elements are case-sensitive
The list of supported cultures is case-sensitive for XNA Game Studio 4.0 Windows Phone projects. This means that the cultures that you list in the <SupportedCultures> property in your .csproj file must exactly match the culture names used in the *.resx files in your project and the *.resources.dll files that are built with your project.
For example, if you have a file named strings.fr-FR.resx in your project, you must put the following in your .csproj:
<SupportedCultures>fr-FR</SupportedCultures>
If you put the following in your .csproj instead of what is listed above, then the French strings.resources.dll that is built from strings.fr-FR.resx may not be packaged into the XAP file for your game (which means that the strings will not be available at runtime on the phone after you deploy your game):
<SupportedCultures>fr-fr</SupportedCultures>
Issue 2 – <SupportedCultures> property cannot be split across lines
By default, a new XNA Game Studio 4.0 Windows Phone project includes a blank list of supported cultures that looks like the following:
<SupportedCultures> </SupportedCultures>
When you add cultures to the <SupportedCultures> property in your .csproj, you must move the closing </SupportedCultures> tag to the same line instead of leaving it on a separate line. For example:
<SupportedCultures>en;fr;it;de;es</SupportedCultures>
If you put the following in your .csproj instead of what is listed above, then the *.resources.dll files that are built or referenced by your project will not be packaged into the XAP file for your game (which means that the strings will not be available at runtime on the phone after you deploy your game):
<SupportedCultures>en;fr;it;de;es </SupportedCultures>
Issue 3 – <SupportedCultures> property might not exist in the .csproj
However, projects created with previous CTP or beta builds of the Windows Phone Developer Tools will not have a <SupportedCultures> property in the .csproj. In order to correctly package *.resources.dll files for your game, you will need to add a <SupportedCultures> property to your .csproj and provide the appropriate list of cultures. You should add the <SupportedCultures> property to the first <PropertyGroup> in your .csproj.