Aaron Stebner's WebLog

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

  • Aaron Stebner's WebLog

    Important uninstall instructions for migrating from the .NET Framework 4 and VS 2010 beta 1 to beta 2

    • 0 Comments

    As noted on Soma’s blog, the .NET Framework 4 beta 2 and Visual Studio 2010 beta 2 have been released today.  If you previously had the .NET Framework 4 beta 1 and/or Visual Studio 2010 beta 1 installed, there are some very important uninstall instructions that you must follow in order to fully uninstall beta 1 so that beta 2 will work correctly.

    If you had the .NET Framework 4 beta 1 and/or VS 2010 beta 1 installed, please follow the instructions at http://go.microsoft.com/fwlink/?LinkID=167718 to fully uninstall beta 1 before you install beta 2.

    These instructions explain how to fully uninstall VS 2010 beta 1 and then fully uninstall the .NET Framework 4 beta 1.  If you do not follow the above instructions, you may see a crash dialog during the installation of VS 2010 beta 2, and you may see package load failures when trying to use VS 2010 beta 2.  The instructions linked above also contain steps to repair the .NET Framework 4 beta 2 and VS 2010 beta 2 in order to recover from these errors.

    If you run into any issues that are not covered by the above instructions, I encourage you to check out the .NET Framework 4 and VS 2010 pre-release forums for additional troubleshooting suggestions and workarounds.

  • Aaron Stebner's WebLog

    Diagnosing and resolving 1935 errors for Win32 assemblies that occur on Windows Vista and later

    • 5 Comments

    Introduction

    1935 errors can occur during an MSI-based installation while installing .NET assemblies or Win32 assemblies.  Most of the workarounds that can be found on blogs and forums (including all of the information in my 1935 error troubleshooting guide) only apply to 1935 errors that happen while installing .NET assemblies.

    This blog post will explain how to troubleshoot 1935 errors that occur while attempting to install Win32 assemblies in an MSI-based installer.

    The information in this blog post only applies to Windows Vista and later versions of Windows, and it also only applies to Win32 assemblies.

    For additional information about troubleshooting 1935 errors that occur on versions of Windows before Windows Vista and that occur for managed (.NET Framework) assemblies, please refer to the 1935 error troubleshooting guide.

    How to identify a 1935 error caused by a Win32 assembly on Windows Vista and later

    For 1935 errors that occur while installing Win32 assemblies in an MSI-based setup (which I have seen most commonly in the past for Visual C++ runtime files), there are some specific diagnosis and troubleshooting steps that you will need to use that are different than the ones used for managed assemblies.

    On Windows Vista and higher, Windows Installer uses the same underlying installation engine as the OS component installation engine (also known as CBS) to install Win32 assemblies.  As a result, anything that can cause an OS update or hotfix to fail to install can cause this type of 1935 error.  You will typically need to do some more in-depth analysis on the affected system in order to narrow down the root cause and identify possible solutions.

    When this type of 1935 error occurs, you will see the following information in a verbose MSI log file:

    MSI (s) (54:32) [12:34:56:789]: Assembly Error (sxs): To get more diagnostic information, enable the Component Based Servicing Log.

    How to identify a root cause and possible solution

    As the above log file entry suggests, there is not enough detailed error information in a verbose MSI log file to determine a root cause of this type of 1935 error.  That means you will need to look in the Component Based Servicing (CBS) log file to try to narrow down the root cause further.  This log file is enabled and created by default on Windows Vista and higher, and it is located at %windir%\logs\cbs\cbs.log.

    You will notice that cbs.log is typically very large and can be difficult to read.  What I typically do is look at the time stamps for the 1935 error messages in the verbose MSI log file, then cross-reference those time stamps with the ones listed in cbs.log to try to find the exact error in cbs.log.  From there, I use the links listed in the blog post at http://blogs.msdn.com/astebner/archive/2009/03/12/9472695.aspx to find more detailed information about the error code that is listed in cbs.log and to try to come up with workarounds from there.

    In some cases, the operating system will lock the file cbs.log so that you cannot open it.  In those cases, it usually works to make a copy of cbs.log in a new location and then open the copy of the file instead.

    Unfortunately, a 1935 error caused by a Win32 assembly on Windows Vista and later can be a pain to diagnose and solve because of the wide range of possible causes.  I have had the most luck in the past by using the System Update Readiness Tool to solve issues related to the OS component installation engine.  There are some steps listed at http://blogs.msdn.com/astebner/archive/2009/01/09/9303167.aspx that I recommend trying in a lot of these scenarios.

    Note - If you see error code 0x800705aa (which means ERROR_NO_SYSTEM_RESOURCES) in your cbs.log file, then it could be caused by the issue described in this discussion thread.

    <update date="1/18/2010"> Added a link to a discussion of error code 0x800705aa in cbs.log. </update>

     

  • Aaron Stebner's WebLog

    Mailbag: How to manage reboots when installing multiple versions of the .NET Framework

    • 2 Comments

    Question:

    I am planning a network deployment of the .NET Framework, and I need to deploy all versions from 1.0 through 3.5 SP1 if any are missing on each of the computers on the network.  I have 2 questions related to reboots:

    1. Is it possible to install all versions of the .NET Framework without any reboot being required?
    2. If it is not possible, can I ignore all reboot prompts and only reboot once after installing all versions of the .NET Framework?

    Answer:

    It is not possible to guarantee with 100% accuracy whether or not a reboot will be needed before running .NET Framework setup.  Reboots during .NET Framework setup are caused by files being in use that need to be updated during the installation process.  Whether or not a reboot will be needed depends on the state of the computer that .NET Framework setup is being run on.  If there are any .NET Framework applications or services running on the computer, then they can lead to reboots being needed during installation of the .NET Framework.

    When deploying the .NET Framework, you should install in silent or unattended mode and rely on the exit codes from the installation processes to determine whether or not a reboot is needed.  All .NET Framework setup packages will return the following exit codes:

    • 0 – installation is successful and no reboot is needed
    • 3010 – installation is successful and a reboot is needed
    • Any other value – installation failed

    If you receive a 3010 exit code from a .NET Framework installation process, you can safely defer the reboot until after you install all versions of the .NET Framework.  However, you must schedule a reboot at the end of the overall installation process if you receive a 3010 exit code from any of the .NET Framework installation processes.  You cannot safely defer a requested reboot if you also plan to install or run a .NET Framework application on the computer.  All .NET Framework applications require that the .NET Framework be fully installed before they will be able to run reliably, including completing any reboots that are requested.

    If you plan to install all versions of the .NET Framework on a computer, you can minimize the number of reboot requests that you might get by doing the following:

    1. If possible, close any .NET Framework applications and stop any .NET Framework services that are running on the computer before running any .NET Framework setup.
    2. Create an administrative install point for the .NET Framework 1.1 + the latest service packs and updates if desired.
    3. Install the .NET Framework 4 if desired.
    4. Install the .NET Framework 3.5 SP1 (which will install the .NET Framework 2.0 SP2 and 3.0 SP2 behind the scenes).
    5. Install the .NET Framework 1.1 + the latest SP from the install point created in step 2.

    Most programs do not specifically require the .NET Framework 1.0 so I didn't list it above.  If you do need the .NET Framework 1.0, you will have to install it before installing the .NET Framework 4 because .NET Framework 4 setup blocks future installation attempts for the .NET Framework 4.  If you need the .NET Framework 1.0, I recommend installing in this order:

    If you plan to install all versions of the .NET Framework on a computer, you can minimize the number of reboot requests that you might get by doing the following:

    1. If possible, close any .NET Framework applications and stop any .NET Framework services that are running on the computer before running any .NET Framework setup.
    2. Create an administrative install point for the .NET Framework 1.1 + the latest service packs and updates if desired.
    3. Create an administrative install point for the .NET Framework 1.0 + the latest service packs and updates if desired.
    4. Install the .NET Framework 3.5 SP1 (which will install the .NET Framework 2.0 SP2 and 3.0 SP2 behind the scenes).
    5. Install the .NET Framework 1.1 + the latest SP from the install point created in step 2.
    6. Install the .NET Framework 1.0 + the latest SP from the install point created in step 3.
    7. Install the .NET Framework 4 if desired.

    Installing the versions of the .NET Framework from newest to oldest will help ensure that the highest versions of any shared files are installed first.  That way, even if the files end up in use during the later installation processes, the .NET Framework setup program will not need to replace them because a higher version will already be installed.

    There are example steps for creating the administrative install points described in steps 2 and 3 above in the blog post at http://blogs.msdn.com/astebner/archive/2005/03/05/385971.aspx.

    <update date="2/8/2011"> Added a separate set of installation instructions for cases where the .NET Framework 1.0 is required because .NET Framework 4 setup prevents the .NET Framework 1.0 from being installed after it. </update>

  • Aaron Stebner's WebLog

    XNA Game Studio 3.1 Zune Extensions now available for download

    • 5 Comments

    The XNA Game Studio 3.1 Zune Extensions was posted on the Microsoft Download Center today.  This product can be installed on a system that has XNA Game Studio 3.1 installed, and it adds the following functionality to the XNA Game Studio 3.1 product:

    • The ability to develop and deploy games to the new Zune HD media player using XNA Game Studio 3.1.
    • New touch APIs to the XNA Framework for use on the Zune HD.
    • New accelerometer APIs to the XNA Framework for use on the Zune HD.
    • New documentation and samples that demonstrate how to use the new touch and accelerometer APIs.
    • A new tutorial demonstrating how to add support for the new touch APIs to the Platformer starter kit that ships with XNA Game Studio 3.1.

    Here are a couple of links to help you get started installing and using the XNA Game Studio 3.1 Zune Extensions:

  • Aaron Stebner's WebLog

    Possible workarounds for project type is not supported by this installation error in XNA Game Studio

    • 2 Comments

    Note - my colleague Yuichi Ito has provided a Japanese version of the information in this blog post.  You can find it at this location on his blog

    Every so often, I hear from a user who has encountered an error like the following while trying to open an XNA Game Studio project in Visual Studio:

    The project type is not supported by this installation.

    There are a couple of common causes that I’ve seen for this type of error, so I wanted to describe each of them here in case they help anyone who encounters this type of error in the future.

    Issue 1: The project file is from a version of XNA Game Studio not installed on the system

    If you have an XNA Game Studio project created with a different version than you have installed on your system (for example, if you download a sample from the Creators Club site or something like that), then you might encounter this error.

    There are automatic upgrade paths for some versions of XNA Game Studio, but not for all of them.  An XNA Game Studio Express 1.0 or 1.0 Refresh game can be opened with XNA Game Studio 2.0.  An XNA Game Studio 2.0 project can be opened with XNA Game Studio 3.0 or 3.1.  An XNA Game Studio 3.0 project can be opened with XNA Game Studio 3.1.  An XNA Game Studio 3.0 or 3.1 project can be opened with XNA Game Studio 4.0.  Other combinations may lead to this error message.

    For example, you cannot open a project created with XNA Game Studio 3.0 on a system that only has XNA Game Studio 2.0 installed or has Visual Studio 2008 but does not have XNA Game Studio 3.0 installed.

    If this is the issue causing the error on your system, you will need to make sure that you have the version of XNA Game Studio installed that the project was created with, or you can create a new project using the version of XNA Game Studio that you have installed and then import the code and content from the original project as a workaround.

    Issue 2: The XNA Game Studio package is not loading properly

    In some cases, XNA Game Studio is installed, but there is some kind of problem that causes it to fail to load correctly in Visual Studio.  I have seen this happen in the past (for example, in this forum post) when a user encountered a package load failure dialog like the following, and then clicked on the Yes button.  Doing this will prevent Visual Studio from loading the XNA Game Studio package in the future (which is why I personally always make sure to click No if I ever encounter a package load failure dialog within Visual Studio):

    If this is the cause of the error message on your system, you can run one of the following command lines from an elevated cmd prompt to reset Visual Studio so that it will not automatically skip loading the XNA Game Studio package the next time you run Visual Studio.

    For XNA Game Studio Express 1.0 and XNA Game Studio 2.0:

    • For Visual Studio 2005 Standard Edition and higher:  "%ProgramFiles%\Microsoft Visual Studio 8\Common7\IDE\devenv.exe" /ResetSkipPkgs
    • For Visual C# 2005 Express Edition:  "%ProgramFiles%\Microsoft Visual Studio 8\Common7\IDE\vcsexpress.exe" /ResetSkipPkgs

    For XNA Game Studio 3.0 and 3.1:

    • For Visual Studio 2008 Standard Edition and higher:  "%ProgramFiles%\Microsoft Visual Studio 9.0\Common7\IDE\devenv.exe" /ResetSkipPkgs
    • For Visual C# 2008 Express Edition:  "%ProgramFiles%\Microsoft Visual Studio 9.0\Common7\IDE\vcsexpress.exe" /ResetSkipPkgs

    For XNA Game Studio 4.0:

    • For Visual Studio 2010 Professional Edition and higher:  "%ProgramFiles%\Microsoft Visual Studio 10.0\Common7\IDE\devenv.exe" /ResetSkipPkgs
    • For Visual C# 2010 Express Edition:  "%ProgramFiles%\Microsoft Visual Studio 10.0\Common7\IDE\vcsexpress.exe" /ResetSkipPkgs
    • For Visual Studio 2010 Express Edition for Windows Phone:  "%ProgramFiles%\Microsoft Visual Studio 10.0\Common7\IDE\vpdexpress.exe" /ResetSkipPkgs

    Note – the above command lines assume that you have installed Visual Studio to the default location and that you are using a 32-bit version of Windows.  You may need to modify the command lines depending on where Visual Studio is installed on your system.  You should use %ProgramFiles(x86)% instead of %ProgramFiles% if you are using a 64-bit version of Windows.

    <update date="11/16/2009"> Added a link to a Japanese version of the information in this blog post.  Thanks Ito! <update>

    <update date="1/29/2011"> Added information about Visual Studio 2010 and XNA Game Studio 4.0. </update>

     

  • Aaron Stebner's WebLog

    Media Center SDK for Windows 7 RTM now available for public download

    • 0 Comments

    As noted in this post on Niall Ginsbourg’s blog and this post on Charlie Owen’s blog, the Windows Media Center SDK for Windows 7 is now available for public download.  Here are some links where you can find the installer and interact with the Windows Media Center developer community:

  • Aaron Stebner's WebLog

    Problem upgrading from Vista to Windows 7 if you have .NET Framework 4 beta 1 installed

    • 0 Comments

    Description of the issue

    There is an issue with the .NET Framework 4 beta 1 and Visual Studio 2010 beta 1 that can cause problems if you do the following:

    1. Install Windows Vista
    2. Install the .NET Framework 4 beta 1 (or Visual Studio 2010 beta 1 because it will install the .NET Framework 4 beta 1 behind the scenes)
    3. Upgrade your OS to Windows 7

    When doing this, some programs that depend on the .NET Framework will not work correctly after you finish your OS upgrade.  Once a system is in this state, there is not a way to repair it other than to re-install Windows 7.

    This issue will be fixed in the .NET Framework 4 beta 2, but will affect systems that have .NET Framework 4 beta 1 installed prior to the OS upgrade.

    How to work around the issue

    To work around this issue, you must do the following in the exact order listed below:

    1. Uninstall VS 2010 beta 1 if it is installed on your system
    2. Uninstall .NET Framework 4 beta 1
    3. Uninstall Visual C++ 2010 beta 1 redistributable if it is installed on your system
    4. Reboot
    5. Upgrade your OS from Windows Vista to Windows 7

    You can find more specific steps that describe how to uninstall all of the above beta 1 products in this post on Aaron Ruckman’s blog.

  • Aaron Stebner's WebLog

    Updated versions of .NET Framework cleanup and verification tools with Windows 7 support

    • 19 Comments

    Over the past week or so, I’ve posted updated versions of both the .NET Framework Cleanup Tool and the .NET Framework Setup Verification Tool.  The primary reason for the updates is to address some specific problems using the tools on Windows 7.  I also fixed a few other issues that customers reported to me or that I discovered in my own testing.

    Here is a list of the changes made to each of the tools:

    .NET Framework Cleanup Tool changes (July 24, 2009):

    • Added logic to correctly cleanup the .NET Framework on Windows 7.  The .NET Framework 2.0 SP2, 3.0 SP2 and 3.5 SP1 are all installed as OS components on Windows 7, so the cleanup tool will not allow you to remove these versions of the .NET Framework on this OS.
    • Added detection and logging for the .NET Framework 4.  The cleanup tool does not yet support cleaning up the .NET Framework 4.  This will be added in a future release.
    • Prevent cleanup of mscoree.dll on Vista and higher.

    .NET Framework Setup Verification Tool changes (July 17, 2009)

    • Fixed false errors being reported for non-English versions of the .NET Framework 1.0.
    • Fixed filtering problem that caused the .NET Framework 1.0 to be removed from the list of available products if any 1.0 service packs are installed.
    • Fixed false errors being reported for the .NET Framework 1.1 if the .NET Framework 1.0 is also installed on the system.
    • Fixed false errors being reported for the .NET Framework 3.5 SP1 on Windows 7.
    • Added detection and logging for .NET Framework 4 and Windows 7.  The verification tool does not yet support verifying the .NET Framework 4.  This will be added in a future release.

    User’s Guides and Download Links

    Here are links to the user’s guides for each of the tools – there are links in each user’s guide that can be used to download the latest version of each tool:

    As always, please let me know (by posting a comment on one of my blog posts or sending me an email) if you run into any issues or have any questions using either of these tools.

  • Aaron Stebner's WebLog

    XNA Creators Club web site has been refreshed

    • 0 Comments

    The XNA Creators Club web site was taken down today, and now it is back up with several changes.  Here are some of the highlights:

    • The name of Xbox LIVE Community Games is now officially Xbox LIVE Indie Games
    • You can now submit games Xbox LIVE Indie Games created with XNA Game Studio 3.1
    • To go along with the release of the Japanese version of XNA Game Studio 3.1, there is now a Japanese version of the Creators Club web site (including Japanese forums), and Japanese creators can now submit Xbox LIVE Indie Games
    • There is now a German version of the Creators Club web site and German creators can now submit Xbox LIVE Indie Games
    • Creators in all supported regions can now submit Xbox LIVE Indie Games for the Japanese, German, Singapore and Swedish Xbox LIVE Marketplaces
    • Consumers will automatically be notified when they run an Xbox LIVE Indie Game and an updated version of the game has been published
    • Creator reputation is now displayed on the Creators Club site.  You can see some of this information directly in your creator card
    • Creators get 50 tokens they can use to give out copies of their game to reviewers, friends, etc.
    • Xbox LIVE Indie Games price points are now 80, 240 and 400 points instead of 200, 400 and 800 points

    I encourage you to check out the Creators Club site to see the above changes in action.

  • Aaron Stebner's WebLog

    Link to additional Avatar animation sample, rigs and animation pack

    • 0 Comments

    Since the release of XNA Game Studio 3.1, we have posted a few samples (described here and here) to help you get started using Avatars in your game.  This week, as announced first on Dean Johnson’s blog, we’ve released an additional Avatar sample along with some utilities to make it easier to create and consume custom Avatar animations in your game.

    Here is some additional information and download links for these new samples and utilities:

    • Custom Avatar Animation Sample - http://creators.xna.com/sample/customavataranimation - This sample shows users how to import, process and play custom Avatar animations though the XNA Framework content pipeline.
    • Avatar Animation Rig - http://creators.xna.com/utility/avataranimationrig – This link provides model and animation rigs for Softimage Mod Tool 7.5 and Maya 2008 that can be used to create custom animations.
    • Avatar Animation Pack - http://creators.xna.com/utility/avataranimationpack - This pack contains 21 new animations that can be consumed in XNA Game Studio 3.1 games.  Examples of the animations in this pack include Jump, Climb, Crawl, Kick, etc.  The animations are available in FBX format for direct use in your games or in source format for both Softimage Mod Tool 7.5 and Maya 2008.
  • Aaron Stebner's WebLog

    Link to information about upgrading WiX v2.0 projects to WiX v3.0

    • 0 Comments

    Now that WiX v3.0 has officially released, you may want to start looking at upgrading your existing setup authoring from WiX v2.0 to WiX v3.0 to take advantage of some of the new WiX v3.0 features.  There are some breaking changes in v3.0, so you cannot simply re-use the same WiX source files from v2.0 with the v3.0 toolset.  Fortunately, there is a tool named WixCop in the WiX v3.0 toolset that will allow you to migrate v2.0 .wxs files to v3.0.

    Rob Mensching wrote a helpful post on his blog last week that introduces WixCop and explains steps that you can use to run WixCop and then update your build scripts to pass in the new WiX extensions that were added in WiX v3.0 so your builds will work correctly.

    You can find Rob’s blog post at http://robmensching.com/blog/posts/2009/7/7/Tips-on-how-to-upgrade-from-WiX-v2-to-WiX-v3.  If you’ve got a WiX v2.0 project that you’re planning to upgrade to WiX v3.0, I encourage you to take a look at Rob’s blog post before you get started with the upgrade project because it will save you a lot of manual migration effort.

    To summarize that blog post, there are 3 main migration steps:

    1. Run %ProgramFiles%\Windows Installer XML v3\bin\WixCop.exe -s –f *.wxs to convert your existing WiX v2.0 source files

      This step assumes that you have WiX v3.0 installed to the default path and that you are running from the directory that your WiX v2.0 source files are located.  You may need to adjust it as appropriate on your system.

    2. Add -ext command line switches and pass in the WiX v3.0 extensions used by your setup authoring when you run candle.exe and light.exe in your build process.

      The easiest way to figure out what extensions you need to pass in for your builds is to try to build and observe any errors you receive related to unhandled extension elements.

    3. If you use WixUI in your WiX v2.0 projects, update your light.exe command line to use the -ext command line switch to pass in the WixUIExtension instead of linking to wixui.wixlib.

    There may be a few migration issues that are not handled by WixCop, but the above steps should get you most of the way there.  Hopefully, the error messages you encounter for any issues not handled by WixCop will be useful enough to lead you to the right solution.  If not, then the WiX user group is a great resource, and so is the WiX v3.0 documentation.

  • Aaron Stebner's WebLog

    Japanese version of XNA Game Studio 3.1 now available for download

    • 0 Comments

    Last night, the XNA Game Studio team released a Japanese version of XNA Game Studio 3.1 and the XNA Framework Redistributable 3.1.  The Japanese news release announcing these products is located at http://www.xbox.com/ja-JP/press/release/20090709.htm.

    Here are some links to help you get started if you want to use the Japanese version of XNA Game Studio 3.1:

    One thing to keep in mind here – it is only supported to install one language of XNA Game Studio 3.1 on your computer at a time.  If you already have the English version of XNA Game Studio 3.1 installed, setup will block you if you try to install the Japanese version afterwards (and vice versa).  You will need to uninstall the English version of XNA Game Studio 3.1 and then install the Japanese version if you prefer to use the Japanese version.

  • Aaron Stebner's WebLog

    Final version of WiX v3.0 now available for download

    • 0 Comments

    Over this past weekend, the 3.0.5419 build of WiX v3.0 was declared the final production build.  If you are using any builds of WiX v3.0 for your projects, I strongly encourage you to update to the 3.0.5419 build at this time.

    Here is some additional information about WiX v3.0 and the final 3.0.5419 build:

  • Aaron Stebner's WebLog

    Updated sample code that supports detection of .NET Framework 4

    • 0 Comments

    I have posted updated versions of the .NET Framework detection code that I have previously written about on my blog that now support detecting the install state of the .NET Framework 4 client and full products.  In addition, I decided to create a new landing page that introduces the 2 versions of the sample code and provides usage information and download locations.

    You can find the landing page at http://blogs.msdn.com/astebner/pages/9763379.aspx.

    The downloads for the updated sample code are listed in this landing page.  There will need to be some slight updates to this sample code when the final version of the .NET Framework 4 releases.  I will keep this code up-to-date as needed in the future.

  • Aaron Stebner's WebLog

    Link to new Object Placement on Avatars sample on the Creators Club site

    • 0 Comments

    Last week, we posted a few Avatar samples on the Creators Club site to help people get started using Avatars in XNA Game Studio 3.1 games.  We’ve just released another useful Avatar sample that I wanted to make sure everyone saw:

    As always, make sure to keep an eye out on the Creators Club site for additional sample content in the future as well.

  • Aaron Stebner's WebLog

    Link to details about sound effect API changes in XNA Game Studio 3.1

    • 0 Comments

    One of my colleagues, Ashu Tatake, started a blog last week.  This week he wrote a helpful post about updates in the XNA Framework sound effect APIs in XNA Game Studio 3.1, so I wanted to link to it here to help more people find it.

    As Shawn Hargreaves described in this blog post, we made some changes in XNA Game Studio 3.1 to fix some issues we discovered with the sound effect APIs originally introduced in XNA Game Studio 3.0.  Shawn’s post describes the scenarios, the problems we found with the 3.0 APIs, and an overview of the changes.

    Ashu follows that up by providing more detailed information about how to migrate existing 3.0 code to 3.1.  If you have any XNA Game Studio 3.0 projects that use sound effect APIs and are planning to upgrade the projects to 3.1, I encourage you to check out Ashu’s blog post for more details about how to identify which audio playback scenarios are most appropriate for your game and how to update your code to adjust for the breaking changes in the sound effect APIs in 3.1.

  • Aaron Stebner's WebLog

    Steps to upgrade an XACT2 project to XACT3 so it can be used with XNA Game Studio 3.1

    • 1 Comments

    If you have an XNA Game Studio project that includes an XACT2 audio project and plan to upgrade it to XNA Game Studio 3.1, there is an additional manual step you must take to upgrade your XACT2 project to XACT3 format.

    There is some information about this scenario in the XNA Game Studio 3.1 documentation.  Unfortunately, the documentation topics don’t list the full error message that you will see if you compile your upgraded project without also upgrading the XACT project, so searching for the error message doesn’t lead to the exact documentation topics that are intended to help in this scenario.  Hopefully this blog post will help guide folks who hit this error in the right direction.

    Description of the issue

    If you have an existing XNA Game Studio 3.0 project that uses an XACT2 audio project, then you upgrade to XNA Game Studio 3.1, you will see an error like the following in the Visual Studio error list when you attempt to compile it with XNA Game Studio 3.1:

    The .xap file was created with a version of XACT that is incompatible with the XNA Framework Content Pipeline version used by this project. Refer to the documentation for options to resolve this mismatch.

    Some guidance about this upgrade issue with XACT projects can be found in the following topics in the documentation:

    • Upgrading XNA Game Studio Projects - in the table of contents, this topic is located at XNA Game Studio 3.1 | Getting Started with XNA Game Studio | Upgrading XNA Game Studio Projects (or via this link if you have XNA Game Studio 3.1 installed).
    • Upgrade Guide: XNA Game Studio 3.0 to XNA Game Studio 3.1 – in the table of contents, this topic is located at XNA Game Studio 3.1 | Getting Started with XNA Game Studio | Upgrading XNA Game Studio Projects | Upgrade Guide: XNA Game Studio 3.0 to XNA Game Studio 3.1 (or via this link if you have XNA Game Studio 3.1 installed).

    The following information in the above topics is applicable to help resolve this XACT compilation error message:

    XNA Game Studio 3.1 projects must use the Microsoft Cross Platform Audio Creation Tool version 3 (XACT3), which is new to XNA Game Studio 3.1. The version of XACT provided with XNA Game Studio 3.0, XACT2, writes project files (.xap) that are incompatible with XNA Game Studio 3.1 projects. XNA Game Studio 3.0 projects must continue to use XACT2. Both versions of XACT are available in the Start menu, under All Programs | Microsoft XNA Game Studio 3.1 | Tools.

    How to update from XACT2 to XACT3 in XNA Game Studio 3.1

    Here are some more specific steps you can use to upgrade an XACT2 project used in XNA Game Studio 3.0 to the version of XACT3 so they can be used by an XNA Game Studio 3.1 project:

    1. On a system with XNA Game Studio 3.1 installed, click on the Start menu, choose All Programs, then Microsoft XNA Game Studio 3.1 | Tools | Microsoft Cross-Platform Audio Creation Tool 3 (XACT3).
    2. In the Microsoft Cross-Platform Audio Creation Tool (XACT) v3.0 tool, open the .xap file from the project that you upgraded from XNA Game Studio 3.0 to XNA Game Studio 3.1.  When it loads, you should see the following message in the XACT UI:

      ---------------------------
      XACT Version Mismatch
      ---------------------------
      This project file was created with the August 2007 release of XACT. You are running the March 2009 release.
      If you save this project, it will be saved as the current version and may no longer work with the version of XACT it was originally created with.
      ---------------------------
      OK  
      ---------------------------

    3. Back up your .xap file before clicking OK if you would like to keep a copy of the old project (an upgrade does not happen automatically).
    4. Click OK to upgrade the .xap project to 3.0 format.
    5. Save the .xap project in the XACT UI and close the XACT UI.
    6. Go back to Visual Studio 2008, open the project that you upgraded from XNA Game Studio 3.0 to 3.1 and choose to build it again.

    Additional notes about this error message

    The steps above explain how to upgrade an XACT2 project created with a previous version of XNA Game Studio to an XACT3 project that can be used with XNA Game Studio 3.1.  However, there are a few different scenarios where the “.xap file was created with a version of XACT that is incompatible with the XNA Framework Content Pipeline version used by this project” error message can occur, so the above workaround may not successfully resolve this error in all cases.

    Here are some of the possible configurations where this error will occur:

    • Attempting to compile an XNA Game Studio 3.1 project that includes an XACT2 project

      This is the scenario that the workaround above applies to

    • Attempting to compile an XNA Game Studio 3.0 project that includes an XACT3 project

      This is the inverse of the above scenario. You need to create a new version of your XACT project using the tool included with XNA Game Studio 3.1 at the following location on the start menu:  All Programs | Microsoft XNA Game Studio 3.1 | Tools | Microsoft Cross-Platform Audio Creation Tool 2 (XACT2).

    • Attempting to compile an XNA Game Studio 3.0 or 3.1 project that includes an XACT project created with a version of the XACT tool other than the ones that ship with XNA Game Studio 3.1 (for example, the version of XACT in the DirectX SDK)

      This is similar to both of the above scenarios.  If you’re using an XNA Game Studio 3.1 project, you need to make sure the XACT project is saved in the format of the version of XACT3 that ships with XNA Game Studio 3.1.  If you’re using an XNA Game Studio 3.0 project, you need to make sure the XACT project is saved in the format of the version of XACT2 that ships with XNA Game Studio 3.0 and 3.1.
  • Aaron Stebner's WebLog

    New XNA Game Studio 3.1 Avatar sample content is now available on the Creators Club site

    • 1 Comments

    As announced in this forum post, there is some new sample content available on the XNA Creators Club site to help you get started creating games in XNA Game Studio 3.1 that take advantage of the new Xbox LIVE Avatar development features.  Here is a quick summary of the new content:

    I also encourage you to check out the following links for more details about using Avatars in your XNA Game Studio 3.1 game:

    Make sure to keep an eye out for additional content on the XNA Creators Club site in the near future as well.

  • Aaron Stebner's WebLog

    Steps to install XNA Game Studio without using the setup bootstrapper

    • 14 Comments

    In the past, we've heard from a few people via the Creators Club forums who have had trouble getting XNA Game Studio setup to run correctly.  In a few cases, such as in this forum post, the setup program (named bootstrapper.exe) crashes shortly after double-clicking on the setup package to launch it.

    If you run into this type of issue with XNA Game Studio 2.0, 3.0, 3.1, 4.0 or 4.0 Refresh setup, you can use the following set of steps to bypass bootstrapper.exe and install the pieces of XNA Game Studio manually. 

    To manually install the XNA Game Studio 4.0 Refresh

    Note - if you are running a 64-bit version of Windows, you will need to use %programfiles(x86)% instead of %programfiles% for the installation paths.

    1. Download xnags40_setup.exe and save it to your hard drive
    2. Run xnags40_setup.exe /x to extract the contents to a folder of your choosing
    3. Go to the folder you extracted to in step 2 and run the MSI named redists.msi

      Note: This MSI will only display a small progress bar while it is installing and will not tell you when it is done.  When the progress bar disappears, continue to the next step.

    4. Run the MSI at %ProgramFiles%\Microsoft XNA\XNA Game Studio\v4.0\Setup\XLiveRedist.msi
    5. Run the MSI at %ProgramFiles%\Microsoft XNA\XNA Game Studio\v4.0\Redist\XNA FX Redist\xnafx40_redist.msi
    6. Run the MSI at %ProgramFiles%\Microsoft XNA\XNA Game Studio\v4.0\Setup\xnaliveproxy.msi
    7. Run the MSI at %ProgramFiles%\Microsoft XNA\XNA Game Studio\v4.0\Setup\xnags_platform_tools.msi
    8. Run the MSI at %ProgramFiles%\Microsoft XNA\XNA Game Studio\v4.0\Setup\xnags_shared.msi
    9. Run the MSI at %ProgramFiles%\Microsoft XNA\XNA Game Studio\v4.0\Setup\xnags_visualstudio.msi
    10. Go to the folder you extracted to in step 2 and run the MSI named arpentry.msi

    To manually install XNA Game Studio 4.0

    Note - if you are running a 64-bit version of Windows, you will need to use %programfiles(x86)% instead of %programfiles% for the installation paths.

    1. Download xnags40_setup.exe and save it to your hard drive
    2. Run xnags40_setup.exe /x to extract the contents to a folder of your choosing
    3. Go to the folder you extracted to in step 2 and run the MSI named redists.msi

      Note: This MSI will only display a small progress bar while it is installing and will not tell you when it is done.  When the progress bar disappears, continue to the next step.

    4. Run the MSI at %ProgramFiles%\Microsoft XNA\XNA Game Studio\v4.0\Setup\XLiveRedist.msi
    5. Run the MSI at %ProgramFiles%\Microsoft XNA\XNA Game Studio\v4.0\Redist\XNA FX Redist\xnafx40_redist.msi
    6. Run the MSI at %ProgramFiles%\Microsoft XNA\XNA Game Studio\v4.0\Setup\xnaliveproxy.msi
    7. Run the MSI at %ProgramFiles%\Microsoft XNA\XNA Game Studio\v4.0\Setup\xnags_platform_tools.msi
    8. Run the MSI at %ProgramFiles%\Microsoft XNA\XNA Game Studio\v4.0\Setup\xnags_shared.msi
    9. Run the MSI at %ProgramFiles%\Microsoft XNA\XNA Game Studio\v4.0\Setup\xnags_documentation.msi
    10. Run the MSI at %ProgramFiles%\Microsoft XNA\XNA Game Studio\v4.0\Setup\xnags_visualstudio.msi
    11. Go to the folder you extracted to in step 2 and run the MSI named arpentry.msi

    To manually install XNA Game Studio 3.1

    Note - if you are running a 64-bit version of Windows, you will need to use %programfiles(x86)% instead of %programfiles% for the installation paths.

    1. Uninstall XNA Game Studio 3.0 if you have it installed
    2. Download xnags31_setup.exe and save it to your hard drive
    3. Run xnags31_setup.exe /x to extract the contents to a folder of your choosing
    4. Go to the folder you extracted to in step 2 and run the MSI named redists.msi

      Note: This MSI will only display a small progress bar while it is installing and will not tell you when it is done.  When the progress bar disappears, continue to the next step.

    5. Run the MSI at %ProgramFiles%\Microsoft XNA\XNA Game Studio\v3.1\Setup\XLiveRedist.msi
    6. Run the MSI at %ProgramFiles%\Microsoft XNA\XNA Game Studio\v3.1\Redist\XNA FX Redist\xnafx30_redist.msi
    7. Run the MSI at %ProgramFiles%\Microsoft XNA\XNA Game Studio\v3.1\Redist\XNA FX Redist\xnafx31_redist.msi
    8. Run the MSI at %ProgramFiles%\Microsoft XNA\XNA Game Studio\v3.1\Setup\xnaliveproxy.msi
    9. Run the MSI at %ProgramFiles%\Microsoft XNA\XNA Game Studio\v3.1\Setup\xnags_platform_tools.msi
    10. Run the MSI at %ProgramFiles%\Microsoft XNA\XNA Game Studio\v3.1\Setup\xnags_shared.msi
    11. Run the MSI at %ProgramFiles%\Microsoft XNA\XNA Game Studio\v3.1\Setup\platformer.msi
    12. Run the MSI at %ProgramFiles%\Microsoft XNA\XNA Game Studio\v3.1\Setup\xnags_documentation.msi
    13. (skip this step if you do not have Visual C# 2008 Express Edition installed) Run the MSI at %ProgramFiles%\Microsoft XNA\XNA Game Studio\v3.1\Setup\xnags_vcsexpress.msi
    14. (skip this step if you do not have Visual Studio 2008 Standard Edition or higher installed) Run the MSI at %ProgramFiles%\Microsoft XNA\XNA Game Studio\v3.1\Setup\xnags_devenv.msi
    15. Go to the folder you extracted to in step 2 and run the MSI named arpentry.msi

    To manually install XNA Game Studio 3.0

    Note - if you are running a 64-bit version of Windows, you will need to use %programfiles(x86)% instead of %programfiles% for the installation paths.

    1. Download xnags30_setup.exe and save it to your hard drive
    2. Run xnags30_setup.exe /x to extract the contents to a folder of your choosing
    3. Go to the folder you extracted to in step 2 and run the MSI named redists.msi

      Note: This MSI will only display a small progress bar while it is installing and will not tell you when it is done.  When the progress bar disappears, continue to the next step.

    4. Run the MSI at %ProgramFiles%\Microsoft XNA\XNA Game Studio\v3.0\Setup\XLiveRedist.msi
    5. Run the MSI at %ProgramFiles%\Microsoft XNA\XNA Game Studio\v3.0\Redist\XNA FX Redist\xnafx30_redist.msi
    6. Run the MSI at %ProgramFiles%\Microsoft XNA\XNA Game Studio\v3.0\Setup\xnaliveproxy.msi
    7. Run the MSI at %ProgramFiles%\Microsoft XNA\XNA Game Studio\v3.0\Setup\xnags_platform_tools.msi
    8. Run the MSI at %ProgramFiles%\Microsoft XNA\XNA Game Studio\v3.0\Setup\xnags_shared.msi
    9. Run the MSI at %ProgramFiles%\Microsoft XNA\XNA Game Studio\v3.0\Setup\platformer.msi
    10. Run the MSI at %ProgramFiles%\Microsoft XNA\XNA Game Studio\v3.0\Setup\xnags_documentation.msi
    11. (skip this step if you do not have Visual C# 2008 Express Edition installed) Run the MSI at %ProgramFiles%\Microsoft XNA\XNA Game Studio\v3.0\Setup\xnags_vcsexpress.msi
    12. (skip this step if you do not have Visual Studio 2008 Standard Edition or higher installed) Run the MSI at %ProgramFiles%\Microsoft XNA\XNA Game Studio\v3.0\Setup\xnags_devenv.msi
    13. Go to the folder you extracted to in step 2 and run the MSI named arpentry.msi

    To manually install XNA Game Studio 2.0

    Note - if you are running a 64-bit version of Windows, you will need to use %programfiles(x86)% instead of %programfiles% for the installation paths.

    1. Download xnags20_setup.exe and save it to your hard drive
    2. Run xnags20_setup.exe /x to extract the contents to a folder of your choosing
    3. Go to the folder you extracted to in step 2 and run the MSI named redists.msi

      Note: This MSI will only display a small progress bar while it is installing and will not tell you when it is done.  When the progress bar disappears, continue to the next step.

    4. Run the MSI at %ProgramFiles%\Microsoft XNA\XNA Game Studio\v2.0\Setup\XLiveRedist.msi
    5. Run the EXE at %ProgramFiles%\Microsoft XNA\XNA Game Studio\v2.0\Redist\DX Redist\DXSETUP.exe
    6. Run the MSI at %ProgramFiles%\Microsoft XNA\XNA Game Studio\v2.0\Redist\XNA FX Redist\xnafx20_redist.msi
    7. Go to the folder you extracted to in step 2 and run the MSI named xnaliveproxy.msi
    8. Go to the folder you extracted to in step 2 and run the MSI named xnags_shared.msi
    9. Go to the folder you extracted to in step 2 and run the MSI named spacewar.msi
    10. Run the MSI at %ProgramFiles%\Microsoft XNA\XNA Game Studio\v2.0\Setup\xnags_documentation.msi
    11. (skip this step if you do not have Visual C# 2005 Express Edition installed) Run the MSI at %ProgramFiles%\Microsoft XNA\XNA Game Studio\v2.0\Setup\xnags_vcsexpress.msi
    12. (skip this step if you do not have Visual Studio 2005 Standard Edition or higher installed) Run the MSI at %ProgramFiles%\Microsoft XNA\XNA Game Studio\v2.0\Setup\xnags_devenv.msi
    13. Go to the folder you extracted to in step 2 and run the MSI named arpentry.msi

    If you end up running into this type of crash, before you proceed with one of the above workarounds, please collect a call stack with Visual Studio or Visual C# Express Edition and report a bug on the Connect site so that we can investigate it further.

    <update date="8/7/2009"> Added clarification about the install step for redists.msi. </update>

     <update date="11/5/2010"> Added information about installing XNA Game Studio 4.0. </update>

     <update date="11/8/2010"> Added a note about the %programfiles(x86)% path on 64-bit versions of Windows. </update>

     <update date="2/22/2012"> Added information about installing the XNA Game Studio 4.0 Refresh. </update>

     

  • Aaron Stebner's WebLog

    XNA Game Studio 3.1 is now available for download

    • 0 Comments

    As announced today in this news item on the Creators Club site, XNA Game Studio 3.1 is now available for download.

    Getting started

    Here are some links with information about how to download and get started using XNA Game Studio 3.1:

    What’s new in XNA Game Studio 3.1?

    XNA Game Studio 3.1 includes the following new features:

    1. Support for Xbox LIVE Avatars
    2. Support for Xbox LIVE Party features
    3. Video playback
    4. Updated audio APIs for “fire-and-forget” scenarios
    5. Support for XACT3
    6. Automatic XNB serialization
    7. XNA Framework multi-targeting in the Visual Studio 2008 and/or Visual C# 2008 Express Edition IDE
    8. Upgrade wizard to convert 3.0 projects to 3.1
    9. An updated version of XNA Game Studio Connect that allows so Creators Club members will be able to deploy and debug their games on an Xbox 360.  If you previously deployed Xbox 360 games using XNA Game Studio 2.0 or 3.0 and the old version of XNA Game Studio Connect, you will need to manually delete and re-download XNA Game Studio Connect, as described in this blog post.
    10. Downloadable content (only for Xbox LIVE Arcade titles that use the XNA Game Studio 3.1 XDK Extensions)

    If you previously had XNA Game Studio 3.0 installed

    XNA Game Studio 3.1 is a replacement for XNA Game Studio 3.0, and this means that you have to uninstall XNA Game Studio 3.0 before you can install XNA Game Studio 3.1.

    Once you install XNA Game Studio 3.1, it can be used to create, build, deploy and debug both 3.0 and 3.1 projects.  Existing 3.0 projects can be opened in XNA Game Studio 3.1 just like they could in XNA Game Studio 3.0, and you are not required to upgrade your 3.0 project to 3.1.  You can also create new 3.0 or 3.1 projects in the New Project dialog in Visual Studio 2008 or Visual C# 2008 Express Edition.

    If you choose to upgrade your 3.0 project to 3.1, you can do so by opening your 3.0 project in XNA Game Studio 3.1, right-clicking on the project in the Visual Studio Solution Explorer, and choosing the Upgrade Solution… menu item.

    For more information about upgrading your 3.0 projects, check out this article on the Creators Club site.

    If you encounter XNA Game Studio 3.1 setup failures

    If you run into setup failures while installing XNA Game Studio 3.1, it can help to look at the log files created by XNA Game Studio 3.0 setup.  They are located at %temp%\XNA Game Studio 3.1 Setup\Logs.

    The best way to get help for setup issues is to gather your log files, upload them to a file server of your choice, and then post a question on the Creators Club general forum that includes a link to your log files.  When doing this, please be sure to search for related issues before posting something because your question may have already been answered.

    You can also report setup issues via the Connect site - please include your log files as attachments when doing this.

    <update date="6/12/2009"> Added a link to a new blog post by Shawn Hargreaves about audio improvements. </update>

     

  • Aaron Stebner's WebLog

    Votive support for Visual Studio 2010 beta has been added to WiX v3.5

    • 0 Comments

    As Bob Arnson recently noted, the WiX virtual team has been working on getting initial builds of WiX v3.5 posted to the SourceForge site.  The build from last week, 3.5.0605.0, includes a couple of big new features contributed by some folks on the Visual Studio team at Microsoft:

    • A version of Votive that integrates into the Visual Studio 2010 beta
    • A new set of detection properties for .NET Framework 4 beta installation states in the WixNetfxExtension
    • A new set of detection properties and registration custom actions for Visual Studio 2010 beta editions in the WixVsExtension

    You can check out these new features starting in build 3.5.0605.0, which is available at http://wix.sourceforge.net/releases/3.5.0605.0/ on the WiX SourceForge site.

    If you encounter any bugs with these new features, please report them on the WiX bug reporting site.  If you have any questions about using these new features or about WiX in general, I encourage you to use the WiX mailing lists.

  • Aaron Stebner's WebLog

    Links to download Japanese versions of Visual Studio 2010 and .NET Framework 4 beta 1

    • 0 Comments

    A couple of weeks ago, I posted links to English download locations for the .NET Framework 4 beta 1 and Visual Studio 2010 beta.  There are now Japanese versions of some of these products available for download, so I wanted to post those download links as well.

    .NET Framework 4 beta 1 Japanese downloads

    Note: The download packages for the .NET Framework 4 beta 1 and .NET Framework 4 client profile beta 1 are the same as for the English beta 1 release.  The difference is that there are now Japanese download pages.  The language pack installs on top of the .NET Framework 4 beta 1 and adds Japanese string resources for runtime exceptions and other types of error messages.

    Visual Studio 2010 beta 1 Japanese downloads

    Here are a few useful links in case you run into issues while installing or using Visual Studio 2010 beta 1 and the .NET Framework 4 beta 1:

  • Aaron Stebner's WebLog

    Possible problem publishing content with ClickOnce in XNA Game Studio 3.0 or 3.1

    • 0 Comments

    I ran into an issue in a Creators Club forum post this week that I wanted to describe in more detail here in case anyone runs into a similar issue in the future.

    In the forum post, a developer was using the animated sprite sample available in this MSDN topic as the starting point for a project, then adding some items to the content project.  Afterwards, they tried to use the Publish command to create a ClickOnce deployment package.  Installing the ClickOnce package on another machine completed, but the game would not run because the content was not deployed along with the game binaries.

    I looked at the project files included in this sample and found that the .csproj file for the Windows game is missing some metadata that is required by the ClickOnce publishing process in XNA Game Studio 3.0 and XNA Game Studio 3.1.  The Windows game .csproj includes the following ItemGroup that references the nested content project:

    <ItemGroup>
      <NestedContentProject Include="Content\Content.contentproj">
        <ContentRootPath>Content</ContentRootPath>
        <Visible>False</Visible>
      </NestedContentProject>
    </ItemGroup>

    XNA Game Studio 3.0 and 3.1 includes logic to automatically include the content in each nested content project in the ClickOnce publishing output.  This logic requires each NestedContentProject element in the .csproj to include a Project child element.  The Project element must be set to a GUID value that exactly matches the value of the ProjectGuid element in the .contentproj file for the content project (including the curly braces - if the GUID has curly braces in the game project, it must also have curly braces in the content project and vice versa).

    In the animated sprite sample referenced above, this would look like the following:

    <ItemGroup>
      <NestedContentProject Include="Content\Content.contentproj">
        <Project>8ebb2a4c-cb7d-46a7-94a2-82f45c712d12</Project>
        <ContentRootPath>Content</ContentRootPath>
        <Visible>False</Visible>
      </NestedContentProject>
    </ItemGroup>

    After adding the Project element listed in bold above to the Windows game .csproj file in the animated sprite sample, the Publish command will correctly include items that are in the game’s content project when creating a ClickOnce deployment package.

    The built-in XNA Game Studio project templates include this Project element by default and set it to the correct GUID value when you instantiate a new project.  Unfortunately, some of the older samples that we created in pre-3.0 versions of XNA Game Studio did not have that element, so it may be necessary to manually fix the .csproj by adding this information if you are discover that the files in your content project(s) are failing to deploy when using ClickOnce publishing.

    One note here – it is possible to invoke the ClickOnce Publish command in XNA Game Studio Express 1.0 and XNA Game Studio 2.0 projects, but the command will not work correctly in those versions of XNA Game Studio.  If you are running into issues with ClickOnce with older versions of XNA Game Studio, you should upgrade to at least XNA Game Studio 3.0 and try again first.  If you still run into issues, check to make sure your project has the above metadata.  If that isn’t the issue either, please contact me and/or post a question on the Creators Club Forums and we’ll be able to help you investigate further.

    <update date="7/14/2009"> Updated post to indicate that this issue can affect XNA Game Studio 3.0 and 3.1, not just 3.0. </update>

    <update date="5/27/2010"> Added a note about curly braces around the project GUID because I ran into a publishing issue recently where content was not published when the GUID in the content project was surrounded by curly braces but the GUID in the NestedContentProject section of the game project was not. </update>

     

  • Aaron Stebner's WebLog

    How to unblock installation of the .NET Framework 4 beta 1 on Windows XP Media Center and Tablet PC Editions

    • 13 Comments

    Question:

    I tried to install the .NET Framework 4 beta 1 and Visual Studio 2010 beta 1 on my Windows XP Media Center system.  It fails to install with an error like the following:

    Microsoft .NET Framework 4 Beta 1 cannot be installed because an incompatible version of .NET Framework (v1.0) is installed on the machine. For more information, see http://go.microsoft.com/fwlink/?LinkId=91126.

    I don’t see any useful information in that link, and I don’t see an option to uninstall the .NET Framework 1.0 in the Add/Remove Programs control panel on my system, so I’m stuck.

    Is there any way I can install the .NET Framework 4 beta 1 and VS 2010 beta 1 on my Windows XP Media Center system?

    Answer:

    Officially, the .NET Framework 4 beta 1 (and therefore VS 2010 beta 1) is not supported on Windows XP Media Center Edition or Windows XP Tablet PC Edition.  However, the wording in the readme is a bit vague.  Item 2.1.1.1 in the .NET Framework 4 beta 1 readme says the following:

    Note: You cannot install the .NET Framework 4 Beta 1 on operating systems that have the .NET Framework 1.0 built in.

    As I previously wrote in this blog post, the .NET Framework 1.0 is installed as an OS component on Windows XP Media Center Edition and Windows XP Tablet PC Edition, and it cannot be uninstalled on those versions of Windows XP.

    If you are running Windows XP Media Center Edition or Windows XP Tablet PC Edition and want to be able to install the .NET Framework 4 beta 1 and VS 2010 beta 1, you can manually rename the following registry value:

    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\policy\v1.0]

    If you do this, there are a few important caveats to keep in mind:

    • Renaming this registry key will cause the .NET Framework 1.0 to not function correctly in some cases.  This is why I suggest renaming the key instead of deleting it.  If you rename it, you can restore it in the future.  You can rename it back immediately after installing the .NET Framework 4 beta 1, but this key will also prevent you from uninstalling the .NET Framework 4 beta 1, so if you do that, you will need to rename it again prior to uninstalling this beta.
    • Renaming this registry key was not officially tested by the Visual Studio and .NET Framework teams, so if you decide to do this, you do so at your own risk and you may run into unforeseen problems.
    • If you delete the above registry key and find that you need to restore it later in order to fix functional problems with the .NET Framework 1.0, you can use the steps in this blog post to repair the version of the .NET Framework 1.0 that is installed as an OS component on Windows XP Media Center Edition and Windows XP Tablet PC Edition.  Alternatively, you can manually re-create the following registry key that is listed in this blog post:

      [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\Policy\v1.0]
      3705 = 3321-3705
  • Aaron Stebner's WebLog

    Using WiX 3.0 to create an MSI-based installer for Visual Studio project templates

    • 2 Comments

    A while back, I wrote a blog post where I introduced a set of Visual Studio 2005 and 2008 project templates that I created to supplement the ones that shipped in one of the earlier versions of the Windows Vista Media Center SDK.  I used WiX v3.0 to create the installer for these project templates.  The process of creating an MSI-based installer for Visual Studio project templates can be a bit tricky at first, so I wanted to walk through an example that demonstrates the steps to create an MSI to install and register Visual Studio project templates in order to hopefully make it easier for folks to create their own installers for Visual Studio project templates in the future.

    I previously posted a set of instructions that describe how to use WiX v2.0 to create installers for Visual Studio project templates.  This time, I am going to post snippets of the WXS file directly in this post and explain what each of the pieces of this installer is doing in more detail.

    I chose to use WiX v3.0 in this example for a couple of key reasons that will make more sense when we walk through the WXS code below:

    • The WixVSExtension contains a set of built-in detection and properties and custom actions for locating versions of Visual Studio and registering new project templates for use in the IDE.  This will save us a lot of work because we won’t have to author these properties and custom actions ourselves.
    • WiX v3.0 contains a new feature called smart cabbing (introduced by Rob Mensching in this blog post).  This feature will optimize package sizes by not including duplicate copies of the same files in the cabs created during the build process.  This is particularly useful for Visual Studio project templates because in many cases, the same project template zip file will be installed to different locations (such as the Visual Studio 2005 template location, the Visual C# 2005 Express template location, the Visual Studio 2008 template location, etc).  Smart cabbing allows us to carry only one copy of each project template zip file, even if we install it for multiple versions or editions of Visual Studio.

    I have posted a downloadable copy of the example that I’m going to use in this blog post at http://cid-27e6a35d1a492af7.skydrive.live.com/self.aspx/Blog%7C_Tools/WiX%20Samples/wix%7C_sample%7C_vs%7C_project%7C_template%7C_installer.zip.  It contains the following information:

    • WiX source files that describe how to build the MSI
    • Project template zip files (the payload of the MSI)
    • A build script that calls Candle and Light (the WiX compiler and linker) to create the MSI
    • A built copy of the sample MSI

    For the rest of this post, I will be walking through the syntax of the file wix_sample_vs_project_template_installer.wxs that is included in the above zip file and that I also posted as a standalone file at http://cid-27e6a35d1a492af7.skydrive.live.com/self.aspx/Blog%7C_Tools/WiX%20Samples/wix%7C_sample%7C_vs%7C_project%7C_template%7C_installer.wxs if you need to quickly reference it without downloading and extracting the entire zip file.

    Import WiX Visual Studio 2005 detection properties and registration custom actions

    WiX v3.0 includes a set of built-in detection properties and custom actions for the Visual Studio 2005 family of products.  When building your project template installer, you will need to decide which (if any) Visual Studio 2005 products that you plan to support, and then import the appropriate properties and custom actions.

    In the example I created, the following statements are used to import the Visual C# 2005 Express Edition, Visual Basic 2005 Express Edition and Visual Studio 2005 Standard Edition and higher detection properties and registration custom actions:

    <PropertyRef Id="VS2005_ROOT_FOLDER" />
    <PropertyRef Id="VS2005_IDE_VCSHARP_PROJECTSYSTEM_INSTALLED" />
    <PropertyRef Id="VS2005_IDE_VB_PROJECTSYSTEM_INSTALLED" />

    <CustomActionRef Id="VS2005Setup" />
    <CustomActionRef Id="VCSHARP2005Setup" />
    <CustomActionRef Id="VB2005Setup" />

    Import WiX Visual Studio 2008 detection properties and registration custom actions

    WiX v3.0 includes a set of built-in detection properties and custom actions for the Visual Studio 2008 family of products.  When building your project template installer, you will need to decide which (if any) Visual Studio 2008 products that you plan to support, and then import the appropriate properties and custom actions.

    In the example I created, the following statements are used to import the Visual C# 2008 Express Edition, Visual Basic 2008 Express Edition and Visual Studio 2008 Standard Edition and higher detection properties and registration custom actions:

    <PropertyRef Id="VS90_ROOT_FOLDER" />
    <PropertyRef Id="VS90_IDE_VCSHARP_PROJECTSYSTEM_INSTALLED" />
    <PropertyRef Id="VS90_IDE_VB_PROJECTSYSTEM_INSTALLED" />

    <CustomActionRef Id="VS90Setup" />
    <CustomActionRef Id="VCSHARP90Setup" />
    <CustomActionRef Id="VB90Setup" />

    Define the Visual Studio 2005 and Visual Studio 2008 templates directory structure

    The next step is to define the installation folder structure for the templates.  You need to define a default folder structure that matches the default installation directories for each of the versions of Visual Studio that you plan to support, and then also include logic to allow your project template installer to install the templates to the correct location if it detects that Visual Studio is installed to a non-default location.

    In the example I created, the following folder structure is used for Visual Studio 2005 project templates.  The Id named VS2005_ROOT_FOLDER matches one of the built-in WiX properties defined above, and it will be set to a non-default location during installation if the user has Visual Studio 2005 installed to a non-default location on their system:

    <Directory Id="TARGETDIR" Name="SourceDir">
      <Directory Id="ProgramFilesFolder" Name="Program Files">
        <Directory Id="VS2005_ROOT_FOLDER" Name="Visual Studio 8">
          <Directory Id="Common7_2005" Name="Common7">
            <Directory Id="IDE_2005" Name="IDE">
              <Directory Id="ProjectTemplates_VS_2005" Name="ProjectTemplates">
                <Directory Id="CSharpProjectTemplates_VS_2005" Name="CSharp">
                  <Directory Id="MceProjectTemplates_Csharp_VS_2005" Name="Windows Media Center"/>
                </Directory>
                <Directory Id="VBasicProjectTemplates_VS_2005" Name="VisualBasic">
                  <Directory Id="MceProjectTemplates_VBasic_VS_2005" Name="Windows Media Center"/>
                </Directory>
              </Directory>
              <Directory Id="VcsExpress_2005" Name="VcsExpress">
                <Directory Id="ProjectTemplates_VCS_Express_2005" Name="ProjectTemplates"/>
              </Directory>
              <Directory Id="VbExpress_2005" Name="VbExpress">
                <Directory Id="ProjectTemplates_VB_Express_2005" Name="ProjectTemplates"/>
              </Directory>
            </Directory>
          </Directory>
        </Directory>
      </Directory>
    </Directory>

    In the example I created, the following folder structure is used for Visual Studio 2008 project templates.  The Id named VS90_ROOT_FOLDER matches one of the built-in WiX properties defined above, and it will be set to a non-default location during installation if the user has Visual Studio 2008 installed to a non-default location on their system:

    <Directory Id="TARGETDIR" Name="SourceDir">
      <Directory Id="ProgramFilesFolder" Name="Program Files">
        <Directory Id="VS90_ROOT_FOLDER" Name="Visual Studio 9.0">
          <Directory Id="Common7_2008" Name="Common7">
            <Directory Id="IDE_2008" Name="IDE">
              <Directory Id="ProjectTemplates_VS_2008" Name="ProjectTemplates">
                <Directory Id="CSharpProjectTemplates_VS_2008" Name="CSharp">
                  <Directory Id="MceProjectTemplates_Csharp_VS_2008" Name="Windows Media Center"/>
                </Directory>
                <Directory Id="VBasicProjectTemplates_VS_2008" Name="VisualBasic">
                  <Directory Id="MceProjectTemplates_VBasic_VS_2008" Name="Windows Media Center"/>
                </Directory>
              </Directory>
              <Directory Id="VcsExpress_2008" Name="VcsExpress">
                <Directory Id="ProjectTemplates_VCS_Express_2008" Name="ProjectTemplates"/>
              </Directory>
              <Directory Id="VbExpress_2008" Name="VbExpress">
                <Directory Id="ProjectTemplates_VB_Express_2008" Name="ProjectTemplates"/>
              </Directory>
            </Directory>
          </Directory>
        </Directory>
      </Directory>
    </Directory>

    Define components to install each of the Visual Studio project templates

    Now that you have defined the installation folder structure, the next step is to define Windows Installer components for each of the project templates you want to install.  There are a few considerations to keep in mind when doing this:

    1. If you plan to support multiple versions or editions of Visual Studio, it is a good idea to put installation conditions on each component so the component will only be installed if the version/edition of Visual Studio that it applies to is present on the user’s system.
    2. If you have any conditions in the component, you should set Transitive=”yes” for that component in your WiX authoring.  The transitive attribute will cause Windows Installer to re-evaluate the condition during a repair.  That is useful if the user installs your product, then adds a new Visual Studio edition and tries to repair your product.  Setting the transitive attribute will allow your product to add your project templates to the newly installed Visual Studio edition during a repair of your product.  If you don’t set the transitive attribute, the user would have to uninstall and then re-install your product to add your project templates to the newly installed Visual Studio edition.
    3. It is possible for a user to install Visual Studio but not install all of the language tools.  Therefore, if you have a C# project template, it is a best practice to not only check to see if Visual Studio is installed, but also to see if the C# project system is installed within Visual Studio.  The same holds true for project templates for other languages (VB, VC++, etc).
    4. If you plan to support both Visual Studio Standard Edition and higher and Visual Studio Express Editions, you should check for the existence of both the Visual Studio root directory (which can be created by either Visual Studio or Express Editions) and the Visual Studio executable for the exact  edition of Visual Studio that the template will be used by.  For example, in a Visual C# Express template, you would check for vcsexpress.exe, and in a Visual Studio Standard Edition or higher template, you would check for devenv.exe.

    In the example I created, the following component is used to install a C# project template for use in Visual Studio 2005 Standard Edition and higher.  Note that it implements the 4 suggestions listed above by including a condition that checks for the VS 2005 root folder, the file devenv.exe and the Visual C# project system and marking the component as transitive:

    <DirectoryRef Id="MceProjectTemplates_Csharp_VS_2005">
      <Component Id="MediaCenterApplicationFundamental_csharp.zip_VS_2005" Guid="{75055686-A7E2-401F-B288-2EC6067E7F7B}" DiskId="1" Transitive="yes">
        <Condition>(VS2005_ROOT_FOLDER AND VS2005DEVENV AND VS2005_IDE_VCSHARP_PROJECTSYSTEM_INSTALLED)</Condition>
        <File Id="MediaCenterApplicationFundamental_csharp.zip_VS_2005" Name="MediaCenterApplicationFundamental.zip" KeyPath="yes" Source="MediaCenterApplicationFundamental_csharp.zip"/>
      </Component>
    </DirectoryRef>

    In the example I created, the following component is used to install the same project template as the one above, but to install it for use in Visual C# 2005 Express Edition instead of Visual Studio 2005 Standard Edition and higher.  Visual Studio Express Editions do not have selectable features, so there is no need to check that the Visual C# project system is installed in this component.

    <DirectoryRef Id="ProjectTemplates_VCS_Express_2005">
      <Component Id="MediaCenterApplicationFundamental_csharp.zip_VCS_2005" Guid="{193E3610-90C5-442C-ACF7-D50C67B4B27C}" DiskId="1" Transitive="yes">
        <Condition>(VS2005_ROOT_FOLDER AND VCSHARP2005EXPRESS_IDE)</Condition>
        <File Id="MediaCenterApplicationFundamental_csharp.zip_VCS_2005" Name="MediaCenterApplicationFundamental.zip" KeyPath="yes" Source="MediaCenterApplicationFundamental_csharp.zip"/>
      </Component>
    </DirectoryRef>

    In the example I created, the following component is used to install the same project template as the one above, but to install it for use in Visual Studio 2008 Standard Edition and higher.

    <DirectoryRef Id="MceProjectTemplates_Csharp_VS_2008">
      <Component Id="MediaCenterApplicationFundamental_csharp.zip_VS_2008" Guid="{70AE985D-706A-4C39-9417-20303DA605AC}" DiskId="1" Transitive="yes">
        <Condition>(VS90_ROOT_FOLDER AND VS90DEVENV AND VS90_IDE_VCSHARP_PROJECTSYSTEM_INSTALLED)</Condition>
        <File Id="MediaCenterApplicationFundamental_csharp.zip_VS_2008" Name="MediaCenterApplicationFundamental.zip" KeyPath="yes" Source="MediaCenterApplicationFundamental_csharp.zip"/>
      </Component>
    </DirectoryRef>

    In the example I created, the following component is used to install the same project template as the one above, but to install it for use in Visual C# 2008 Express Edition.

    <DirectoryRef Id="ProjectTemplates_VCS_Express_2008">
      <Component Id="MediaCenterApplicationFundamental_csharp.zip_VCS_2008" Guid="{92C85077-C8EB-40F9-82F3-1887B9EA111E}" DiskId="1" Transitive="yes">
        <Condition>(VS90_ROOT_FOLDER AND VCSHARP90EXPRESS_IDE)</Condition>
        <File Id="MediaCenterApplicationFundamental_csharp.zip_VCS_2008" Name="MediaCenterApplicationFundamental.zip" KeyPath="yes" Source="MediaCenterApplicationFundamental_csharp.zip"/>
      </Component>
    </DirectoryRef>

    All 4 of the above components use the same Source value in the File element, so the WiX v3.0 smart-cabbing feature will optimize the build process to include only one copy of the project template .zip file in your installer payload.  This can save a lot of disk space when creating installers for Visual Studio project templates that target multiple versions/editions of Visual Studio.

    Block installation if the necessary version of Visual Studio is not installed

    In addition to including component conditions, I also suggest that you include blocking logic in your project template installer if none of the supported Visual Studio editions/versions are installed on the user’s system.  If your project template installer only supports a single edition and version of Visual Studio, this type of block is simple to author.  However, if you plan to support multiple editions and/or versions of Visual Studio, you need to carefully author the block so it won’t be overly aggressive.

    In the example I created, the project templates support all of the following: Visual Studio 2005 Standard Edition and higher, Visual C# 2005 Express Edition, Visual Basic 2005 Express Edition, Visual Studio 2008 Standard Edition and higher, Visual C# 2008 Express Edition, and Visual Basic 2008 Express Edition.  The following logic will cause installation to block if none of these Visual Studio editions or versions are installed, but will allow install to proceed if at least one of them is installed (and in that case, it will rely on the component conditions described above to only integrate into Visual Studio versions/editions that are actually installed):

    <CustomAction Id="CA_BlockIfVSIsNotInstalled" Error="!(loc.LaunchCondition_MissingVS)" />

    <InstallExecuteSequence>
      <Custom Action="CA_BlockIfVSIsNotInstalled" Before="CostInitialize">(NOT VS2005_ROOT_FOLDER OR NOT VS2005DEVENV) AND NOT VCSHARP2005EXPRESS_IDE AND NOT VB2005EXPRESS_IDE AND (NOT VS90_ROOT_FOLDER OR NOT VS90DEVENV) AND NOT VCSHARP90EXPRESS_IDE AND NOT VB90EXPRESS_IDE AND NOT Installed</Custom>
    </InstallExecuteSequence>

    <InstallUISequence>
      <Custom Action="CA_BlockIfVSIsNotInstalled" Before="CostInitialize">(NOT VS2005_ROOT_FOLDER OR NOT VS2005DEVENV) AND NOT VCSHARP2005EXPRESS_IDE AND NOT VB2005EXPRESS_IDE AND (NOT VS90_ROOT_FOLDER OR NOT VS90DEVENV) AND NOT VCSHARP90EXPRESS_IDE AND NOT VB90EXPRESS_IDE AND NOT Installed</Custom>
    </InstallUISequence>

    The custom action is included in both the InstallExecuteSequence and the InstallUISequence so that the installation block will occur if the user runs the project template installer in UI mode or in silent mode.

    Provide progress UI strings that will be displayed during installation

    The Visual Studio custom actions that register new project templates can take a while to run, especially if the user has a lot of Visual Studio add-ins, packages and templates on their system.  To help improve the installation experience, I recommend defining strings that will appear in the progress UI while the Visual Studio registration custom actions are running in your project template installer.

    In the example I created, the following ProgressText entries will provide descriptive text for each of the Visual Studio 2005 and Visual Studio 2008 registration custom actions.  Note that the Action names in these entries must match the names of the built-in WiX v3.0 custom actions that were imported earlier in this blog post or the progress text will not appear during installation.

    <UI>
      <ProgressText Action="VS2005Setup" Template="[1]">!(loc.Devenv_Setup_VS2005_Description)</ProgressText>
      <ProgressText Action="VCSHARP2005Setup" Template="[1]">!(loc.Devenv_Setup_VCS2005_Description)</ProgressText>
      <ProgressText Action="VB2005Setup" Template="[1]">!(loc.Devenv_Setup_VB2005_Description)</ProgressText>
      <ProgressText Action="VS90Setup" Template="[1]">!(loc.Devenv_Setup_VS2008_Description)</ProgressText>
      <ProgressText Action="VCSHARP90Setup" Template="[1]">!(loc.Devenv_Setup_VCS2008_Description)</ProgressText>
      <ProgressText Action="VB90Setup" Template="[1]">!(loc.Devenv_Setup_VB2008_Description)</ProgressText>
    </UI>

    Add upgrade logic for future versions of the installer

    This step is something I tend to add to all installers I create and is not specific to Visual Studio project template installers.  I typically use steps like the ones in this blog post to add logic to enable Windows Installer major upgrades.  This gives you more flexibility in case you decide to release a new version of your installer in the future and want it to replace older versions.

Page 7 of 48 (1,186 items) «56789»