Aaron Stebner's WebLog

Thoughts about setup and deployment issues, WiX, XNA, the .NET Framework and Visual Studio

March, 2011

  • Aaron Stebner's WebLog

    How to open a Windows Phone .sln file in Visual Studio 2010 Professional instead of Visual Studio 2010 Express for Windows Phone

    • 3 Comments

    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.

  • Aaron Stebner's WebLog

    Link to new Windows Phone 7 game development book by 2 XNA MVPs

    • 0 Comments

    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.

  • Aaron Stebner's WebLog

    ClickOnce publishing does not work for an XNA Game Studio 4.0 Windows game upgraded from 3.0 or 3.1

    • 0 Comments

    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:

    1. Open your XNA Game Studio 3.1 Windows game project in a supported VS 2010 edition (Professional, Premium, Ultimate, Visual C# 2010 Express, Visual Studio 2010 Express for Windows Phone)
    2. Follow the steps in the Visual Studio Conversion Wizard to upgrade the project to XNA Game Studio 4.0
    3. After upgrade is complete, update your game code to address any breaking changes between the XNA Framework 3.1 and 4.0
    4. Right-click on the project in the Visual Studio solution explorer and choose Properties
    5. Click on the Publish tab on the left side of the Properties window
    6. Click on the Prerequisites… button
    7. In the Prerequisites dialog, check the item named Microsoft .NET Framework 4 Client Profile (x86 and x64), uncheck any other .NET Framework versions that are currently checked, and uncheck the Microsoft XNA Framework Redistributable 3.1
    8. Save your project and publish your project to create a ClickOnce package and a setup.exe bootstrapper for it
  • Aaron Stebner's WebLog

    Possible workarounds for localization build issues in XNA Game Studio 4.0 Windows Phone games

    • 0 Comments

    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

    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>

    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.

Page 1 of 1 (4 items)