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.
As announced earlier today on the XNA Game Studio team blog, registration is now open for the Dream.Build.Play 2011 Challenge. Here is a quick summary of the key information about the Dream.Build.Play 2011 Challenge:
I encourage you to check out the Dream.Build.Play 2011 web site for more detailed information and to register for the contest.
I found a link on the App Hub forums today that I wanted to pass on. Jim Perry, one of the XNA MVPs, has posted a Windows version of the XNA Game Studio 4.0 platformer starter kit that is merged with the game state management sample to provide a full menu system for the game. He posted the base version and all of the extended versions of the platformer starter kit (extra lives, scrolling level, power ups).
You can find the blog post and download links at http://machxgames.com/blog/?p=27.
I ran the .NET Framework cleanup tool and removed all versions of the .NET Framework from my computer. Why do I still see the .NET Framework listed in the Programs and Features control panel after removing it with the cleanup tool?
Just because an item is listed in the Programs and Features control panel (on Windows Vista and higher) or the Add/Remove Programs control panel (on Windows XP, Windows Server 2003 and earlier), it does not mean that the product is actually installed. The Programs and Features control panel lists all items that appear in a specific part of the registry.
On a 32-bit OS:
On a 64-bit OS:
The .NET Framework cleanup tool removes some of the .NET Framework-related registry keys at the above locations, but it does not have the ability to remove those registry keys for every previously shipped .NET Framework hotfix. As a result, the .NET Framework might still appear in the list of installed programs in the Programs and Features control panel even after running the cleanup tool.
Please note that the .NET Framework cleanup tool is not designed to be a replacement for the standard .NET Framework uninstall process. It is only designed as a last resort for cases where install, uninstall, repair or patch installation did not succeed for unusual reasons. You should always try the uninstall steps listed in this blog post before resorting to using the .NET Framework cleanup tool.
As I mentioned in a previous blog post, the Windows Phone Developer Tools January 2011 Update was released a few days ago. Since then, I’ve heard from a few people who have reported installation issues that I wanted to describe in a bit more detail in case others run into them in the future.
Issue 1 – Windows Phone Developer Resources patch silently exits when it is done installing
The Windows Phone Developer Resources patch that is a part of the Windows Phone Developer Tools January 2011 Update only displays a small dialog with a progress bar during the installation process.
The installation process can take a long time on some computers because it needs to re-generate the saved state file for the updated emulator image, and it may appear to be hung with the progress bar registering 100% complete while it does this. You should not not try to close setup or kill it with the Task Manager during this time.
When the installation process completes, the small dialog with the progress bar disappears, but there is no indicator that setup is complete or that it succeeded. You can determine whether or not this patch successfully installed by doing the following (this is copied from the January 2011 Update release notes):
Issue 2 – Visual Studio patch fails on a system that has the Visual Studio 2010 SP1 beta installed
The Visual Studio patch that is a part of the Windows Phone Developer Tools January 2011 Update will not install correctly if the computer it is being installed on has the Visual Studio 2010 SP1 beta installed. If you have the Visual Studio 2010 SP1 beta, you will need to uninstall it and then use the following steps to restore Visual Studio 2010 before you can install the Visual Studio patch:
As announced earlier today in this post on the Windows Phone Developer Blog and in this news item on the App Hub site, the Windows Phone Developer Tools January 2011 Update is now available for download.
How to install the update?
The Windows Phone Developer Tools January 2011 Update consists of 2 patches that install on top of the original Windows Phone Developer Tools RTW release, so you must install all of the following items in order to fully install the update:
You do not need to uninstall the Windows Phone Developer Tools October 2010 Update if you previously installed it. The January 2011 Update will install over the top of it and will replace it.
Note – in some cases, installing the patches can cause the default deployment target to change from the Windows Phone 7 Emulator to the Windows Phone 7 Device. If that happens on your computer, you can use the steps listed in this blog post to reset the default deployment target.
What is included in the update?
The Windows Phone Developer Tools January 2011 Update includes an updated version of the Windows Phone 7 Emulator. The updated emulator adds support for copy and paste functionality so that developers can test this functionality in their applications. It also includes several bug fixes and performance enhancements. Note that this functionality will not be available to Windows Phone 7 devices until a future update is released.
In addition, because it is a cumulative update, this update also includes the following components that originally shipped in the Windows Phone Developer Tools October 2010 Update:
Who should install this update?
I encourage all developers creating applications or games for Windows Phone 7 to install this update. It makes the process of developing, testing and submitting to the Windows Phone Marketplace more smooth, and provides emulator support for upcoming Windows Phone 7 OS functionality so you can start testing your applications and games with these changes before the OS update is released.
In nearly all cases, applications and games that have already been released will not need to be recompiled or resubmitted to the Windows Phone Marketplace as a result of this update. There is a specific scenario where a recompile and resubmit is encouraged – if you have pivot or panorama controls that contain text boxes, users can unintentionally change panes when trying to use the new copy and paste feature to copy text into the text box. To prevent this problem, you can install the Windows Phone Developer Tools January 2011 Update, open your application, recompile it, and then resubmit it to the Windows Phone Marketplace.
Getting started links
Here are some download links to help you get started with the Windows Phone Developer Tools January 2011 Update:
Here are some documentation links to help you get started with new features:
XNA Game Studio 4.0 supports the following editions of Visual Studio 2010: Visual Studio 2010 Professional and better, Visual C# 2010 Express, and Visual Studio 2010 Express for Windows Phone. However, as described in more detail in this blog post, XNA Game Studio 2010 does not support developing games for all platforms in all of these Visual Studio 2010 editions. There is a specific unsupported scenario that gives a pretty poor error message if you try it, and I want to describe it in a little more detail here in case anyone runs into it while using XNA Game Studio 4.0.
Description of the issue
You can create XNA Game Studio 4.0 Windows Phone game projects in Visual Studio 2010 Professional and better or Visual Studio 2010 Express for Windows Phone, but not in Visual C# 2010 Express. However, because the overall XNA Game Studio 4.0 project system supports Visual C# 2010 Express, you can open XNA Game Studio 4.0 Windows Phone game projects that were created elsewhere in Visual C# 2010 Express. If you do this, you can edit the phone game projects and build them with no errors. If you attempt to press F5 to deploy and debug a phone game, you will see an error like the following:
Unable to start debugging. An error occurred that usually indicates a corrupt installation (code 0x80040154). If the problem persists, repair your Visual Studio installation via 'Add or Remove Programs' in Control Panel.
Unable to start debugging.
An error occurred that usually indicates a corrupt installation (code 0x80040154). If the problem persists, repair your Visual Studio installation via 'Add or Remove Programs' in Control Panel.
Repairing Visual C# 2010 Express will not help in this scenario. There are certain components that are required for Windows Phone development that are only available in Visual Studio 2010 Professional and better or Visual Studio 2010 Express for Windows Phone, and as a result, you cannot deploy or debug Windows Phone game projects in Visual C# 2010 Express.
How to work around this issue
If you run into the above error, you will need to open your Windows Phone game project (.csproj) file in one of the supported Visual Studio 2010 editions and deploy and debug it from there instead.
A note about Silverlight Windows Phone projects
One other note about this scenario – if you attempt to open a Silverlight Windows Phone application project that was created elsewhere in Visual C# 2010 Express, you will see an error like the following and will not even be allowed to open it:
error : The project file 'C:\Users\myuser\Documents\Visual Studio 2010\Projects\WindowsPhoneApplication1\WindowsPhoneApplication1\WindowsPhoneApplication1.csproj' cannot be opened. The project type is not supported by this installation.
error : The project file 'C:\Users\myuser\Documents\Visual Studio 2010\Projects\WindowsPhoneApplication1\WindowsPhoneApplication1\WindowsPhoneApplication1.csproj' cannot be opened.
The project type is not supported by this installation.
This message error is more clear, and it prevents you from being able to edit or build the project as well, which helps reinforce the lack of support for Visual C# 2010 Express in a way that XNA Game Studio 4.0 does not. The reason that Silverlight projects are able to present more clear errors in this type of scenario is that the Silverlight Windows Phone project system does not support Visual C# 2010 Express at all, whereas the XNA Game Studio 4.0 project system supports Visual C# 2010 Express, but not for all types of game projects.
Rob Mensching posted an item on his blog today declaring WiX v3.5 complete. The final build number is 3.5.2519.0 and it can be downloaded from http://wix.codeplex.com/releases/view/60102.
Here are a few brief highlights of what is included in WiX v3.5:
As noted on the XNA Game Studio team blog and this App Hub news item, the deadline for submitting Xbox LIVE Indie Games created with XNA Game Studio 3.1 to play-testing or peer review is only one week away. Here are the key things to keep in mind:
Rob Mensching announced on his blog yesterday that the build that is likely to be the final build of WiX v3.5 is now available to download. The v3.5.2519 build contains a couple of targeted fixes for bugs reported since the 2nd escrow build was declared in December, and it will be the final build of WiX v3.5 if no ship-stopping bugs are found.
If you are using WiX to create Windows Installer packages for your products, I strongly encourage you to upgrade to this build of WiX v3.5 and help the WiX virtual team validate that this build is ready to be declared the final WiX v3.5 build. Here are a couple of links to help get you started:
I’m a little late posting this information since the book was released at the end of December, 2010, but my co-workers Tom Miller and Dean Johnson wrote a book titled XNA Game Studio 4.0 Programming: Developing for Windows Phone 7 and Xbox 360, and one of my other co-workers, Shawn Hargreaves, wrote the foreword for the book.
You can find more information about the book at the following locations:
I got a copy of this book last week, and now I need to remember to go find Tom, Dean and Shawn and get them to autograph it.
XNA Game Studio 4.0 and the XNA Framework 4.0 introduced several breaking API changes. They are described at a high-level in the documentation and some of them are described in more detail on Shawn Hargreaves’ blog. These breaking changes present challenges to developers when they try to upgrade their games from XNA Game Studio 3.0 or 3.1 to 4.0. XNA Game Studio 4.0 includes a built-in upgrade wizard that will upgrade 3.0 and 3.1 projects to 4.0, but the upgrade process only updates meta-data in the project files (such as .csproj and .contentproj). Like the upgrade wizards for other Visual Studio project types, it does not attempt to make any changes to the code in the projects. This is because it can be difficult to reliably tell what the intent is of a given piece of code, and in many cases there are multiple options that could be valid solutions for breaking changes.
Fortunately, someone recently posted a cheat sheet with more details to help map compile errors that can occur after upgrading a 3.0 or 3.1 game to 4.0 to the options that you have to update your code so it will compile successfully with 4.0. If you are running into any issues fixing your game to react to breaking changes in XNA Game Studio 4.0, I encourage you to take a look at the cheat sheet at http://www.nelxon.com/blog/xna-3-1-to-xna-4-0-cheatsheet/.
I have heard from a few customers since the release of the .NET Framework 4 who have installed the .NET Framework 4 on Windows Vista or higher and setup reported success, but they see an error when running the .NET Framework setup verification tool. I wanted to describe this scenario in a bit more detail, including how to diagnose whether or not your computer is running into this issue based on the setup log files.
How to quickly tell if this blog post might apply to you
Before reading this whole post, here is a quick way you can check whether or not you are likely to be encountering the issue described below:
Symptoms of the problem
In the cases I’ve seen so far, the .NET Framework setup verification tool reported an error like the following when it tried to run a .NET Framework test application that is bundled with it:
****ERROR**** Process 'Netfx40TestApplication.exe' exited with return code -2146232576
****ERROR**** Process 'Netfx40TestApplication.exe' exited with return code -2146232576
This return code translates to 0x800131700, which is a .NET Framework common language runtime (CLR) error code that means “Failed to load the runtime.” In other words, this return code means that this version of the .NET Framework runtime failed to load at all on this computer.
Further investigation on the computers that exhibited this behavior showed that the file mscoree.dll (which is located in %windir%\system32 and/or %windir%\syswow64) had a version number of 2.0.*. This file is shared by all versions of the .NET Framework, and it should always have a version of at least 4.0.* after installing the .NET Framework 4. If this file is not updated to version 4.0.*, the CLR loader will be unable to load the .NET Framework 4, and it will cause the type of failure in the .NET Framework verification tool that I described above.
Gathering more detailed information from .NET Framework setup log files
I wasn’t sure how a computer could be in a state where .NET Framework 4 setup reported a successful installation but yet mscoree.dll was still versioned 2.0.*. I had the customers use the instructions in this blog post to gather their .NET Framework setup log files, and I started looking at the logs to narrow this issue down further.
In the cases I’ve seen so far, I found an error like the following in the log file named Microsoft .NET Framework 4 Setup_*.html:
Exe (C:\Users\myusername\AppData\Local\Temp\Microsoft .NET Framework 4 Setup_4.0.30319\Windows6.1-KB958488-v6001-x64.msu) failed with 0x80240017 - (null).
Exe (C:\Users\myusername\AppData\Local\Temp\Microsoft .NET Framework 4 Setup_4.0.30319\Windows6.1-KB958488-v6001-x64.msu) failed with 0x80240017 - (null).
The .msu file listed in the above error message is one of the ones that are responsible for updating mscoree.dll to version 4.0.* on Windows Vista and later versions of Windows. Return code 0x80240017 means that the .msu file is not applicable on the computer it is being installed on. This type of return code can occur for several different reasons:
.NET Framework 4 setup prevents cases #1 and #2 from happening behind the scenes, but it cannot prevent cases #3, #4 or #5. To complicate things further, it is not possible to reliably distinguish from this return code which of the cases is the actual cause of the return code. Even worse, case #3 is a case that should be treated the same as a successful installation of this .msu as opposed to a failure.
As a result, the .NET Framework 4 setup ignores this error and treats it as a successful installation of this .msu (case #3). This is why you will see information like the following later in the log file:
Error 0x80240017 is mapped to Custom Error: Success
Error 0x80240017 is mapped to Custom Error: Success
Narrowing down the root cause based on the log files
Because mscoree.dll was not updated like it should have been on the affected computers, I made an educated guess that the customers who contacted me were running into case #4 on their computers. I was able to confirm this in the following ways:
Possible solutions for this type of error
<update date="12/30/2010"> Added a note about pre-release versions of Windows causing this error as well. </update>
<update date="7/27/2011"> Added a note about using SFC to repair Windows files, as suggested in Peter Marcu's blog. </update>
<update date="11/8/2011"> Added a direct link to Peter Marcu's blog post about this issue. </update>
<update date="6/6/2012"> Fixed broken link in the "Gathering more detailed information" section. </update>
I used the instructions and the cleanup tool in this blog post to remove all versions of the .NET Framework from my computer, and now I want to re-install them. Do I need to re-install them in any specific order?
In general, the versions of the .NET Framework allow you to install in any order you choose. However, I recommend installing in reverse order from newest to oldest, like this:
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 1.0. If you need the .NET Framework 1.0, I recommend installing in this order:
Even though it is a little counter-intuitive, there are a couple of reasons that I recommend installing in reverse order:
<update date="1/31/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>
My colleague Shawn Hargreaves wrote a helpful blog post last week that gives more detailed information about how to use isolated storage APIs in an XNA Game Studio Windows game. It includes some settings that you can change in the Visual Studio IDE so that you can use the GetUserStoreForApplication API during debugging without needing to deploy your game using ClickOnce.
If you are using isolated storage APIs in a Windows game, I strongly encourage you to check out Shawn’s post at http://blogs.msdn.com/b/shawnhar/archive/2010/12/16/isolated-storage-windows-and-clickonce.aspx for more information to help you during development and debugging of your game.
A little while ago, I wrote a blog post with a list of steps that you can use to create native resource DLLs so that you can localize the title of your Windows Phone game created with XNA Game Studio 4.0. Today, I found a blog post about a tool that automates the process of creating these native resource DLLs. This tool provides 2 really nice benefits:
You can find the tool in this blog post. Here is a set of steps that use this tool that you can use in place of the ones I posted in my earlier blog post to enable title localization for your Windows Phone game created with XNA Game Studio 4.0:
Step 0 – Create a Windows Phone game project
Step 1 – Create native resource DLLs using the Windows Phone 7 Title Localizer tool
Step 2 – Add native resource DLLs to your Windows Phone game project
Note - the name of the native resource DLL is important in this scenario. It must be named AppResLib.dll, and the localized versions must be named AppResLib.dll.*.mui. If they are named differently, your game will be rejected by the Windows Phone Marketplace certification process.
Step 3 – Update your Windows Phone game to load title strings from the resource DLLs
Update the application title by doing the following:
Update the tile title by doing the following:
The tile title is the name that is displayed if you click and hold on your application/game in the Windows Phone OS and choose to pin it to the start menu. There is some additional information about these properties and how to configure them in XNA Game Studio games in this documentation topic. Depending on the scenarios you want to support for your game, it may not be necessary to create separate strings for your application title and tile title. If you plan to use the same string for both, you do not need to create separate entries in the string table in each of your native resource DLLs in the instructions above.
Step 4 – Rebuild your Windows Phone game solution
Rebuild the solution that contains your Windows Phone Game project.
<update date="1/18/2011"> Added a warning about the naming of the DLL needing to exactly match what is listed in the documentation. </update>
Rob Mensching announced on his blog last week that WiX v3.5 is now in escrow mode, which means that there were zero active bugs when the v3.5.2325 build was produced, and the final release of WiX v3.5 will be happening very soon. If no showstopper bugs are found and fixed, this build will be the final build of WiX v3.5.
Earlier this week, a co-worker ran into an error while installing XNA Game Studio on his computer, and he asked me for help figuring out what caused the problem. I realized that I follow essentially the same set of steps to narrow down the root cause every time I run into an XNA Game Studio setup problem. I want to post these steps on my blog to try to help teach people how to identify root causes and hopefully help solve XNA Game Studio setup problems on their own instead of always needing to rely on a setup expert to analyze and interpret their log files.
Here are the steps I use to narrow down the root cause of an XNA Game Studio setup failure:
Bootstrapper.exe Error: 0 : In Task InstallPlatformTools: MSI Task Processor Failed on task: Installing XNA Game Studio Platform Tools \n Please consult C:\Users\myusername\AppData\Local\Temp\XNA Game Studio 4.0 Setup\Logs\xnags_platform_tools-20101025.180123.LOG for additional log information.
You can see a specific example of this technique in this blog post about troubleshooting XnaLiveProxy installation problems.
The above steps will not work for 100% of all possible XNA Game Studio setup failures, but based on my past experience, they will work in most cases. Finding the root cause is only the first step, and the steps you need to take to solve a setup problem will vary depending on what the root cause is. I’ve found that some setup problems have solutions that are pretty self-explanatory once you know what the root cause is though, so hopefully the above steps will help some people be able to more quickly diagnose and solve XNA Game Studio installation problems.
As always, if you run into a problem that you are unsure of the resolution for or if you have trouble interpreting the information in the XNA Game Studio setup log files, please post a comment on the App Hub forums and/or contact me. When posting on the forums, please zip your XNA Game Studio setup log files, upload the zip file to a file server (such as http://skydrive.live.com) and include a link to the log files in your post to allow us to investigate and offer workarounds more quickly.
XNA Game Studio setup log file locations
XNA Game Studio setup creates setup log files at the following locations:
As noted on the XNA Game Studio team blog today, the Xbox LIVE Indie Games publishing pipeline is now accepting XNA Game Studio 4.0 games in addition to XNA Game Studio 3.1 games. This was originally scheduled to be enabled last Friday, but it slipped out a few days due to a couple of last minute issues that we ran into at the end of last week. As a result, the 90 day window when you will still be able to submit XNA Game Studio 3.1 games has been moved out accordingly. The last day you will be able to submit an XNA Game Studio 3.1 game for Xbox LIVE Indie Games is Monday, February 7, 2011.
Please see the following locations for more information about supported versions of XNA Game Studio for Xbox LIVE Indie Games and Xbox 360:
A while back, I wrote a blog post describing how to extract the contents of the XNA Game Studio 2.0, 3.0 and 3.1 setup packages and install the components manually in case the normal installation process fails. I just went back and updated that blog post to also list the steps for extracting and manually installing XNA Game Studio 4.0.
I’ve gone back and forth about whether or not to update this type of older blog posts in place as new product versions are released or post new ones. In this case, I decided to update the existing post since I can then have a single location to point people to for all versions of XNA Game Studio. However, I also wanted to post a new item about this to help improve visibility since I’m not sure how often folks go back and look at older content.
Here is a copy of the steps I added for XNA Game Studio 4.0. Note - for the instructions below, if you are running a 64-bit version of Windows, you will need to use %programfiles(x86)% instead of %programfiles% for the installation paths.
Please refer to the previous post for instructions for all versions of XNA Game Studio.
To manually install XNA Game Studio 4.0
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.
<update date="11/8/2010"> Added a note about the %programfiles(x86)% path on 64-bit versions of Windows. </update>
<update date="11/21/2011"> Removed an incorrect step from the list. </update>
Last month, there was an item posted on the XNA Game Studio team blog with a rough timeline for when to expect the final release of the 4.0 version of XNA Game Studio Connect and the opening of the Xbox LIVE Indie Games publishing pipeline for 4.0 games. Today, the exact release dates were announced in this new post on the XNA Game Studio team blog and in this news item on the App Hub site. Here is a summary of the key information announced there:
Stay tuned to the App Hub site on Friday, November 5, 2010 for the official announcement that the Xbox LIVE Indie Games publishing pipeline is open for 4.0 games. There will also be reminders over the next 90 days as the end of the window to submit games created with XNA Game Studio 3.1 approaches.
As announced earlier this week in this post on the Windows Phone Developer Blog, the Windows Phone Developer Tools October 2010 Update is now available for download. This update is a patch, so you must install the Windows Phone Developer Tools before you will be able to install the update.
This update includes the following components:
Here are some links to help you get started with the Windows Phone Developer Tools October 2010 Update:
At the end of last week, the XNA Game Studio team released the XNA Game Studio 4.0 Japanese language pack. I wanted to provide some more information about this language pack and some download links to help you get started. My colleague Yuichi Ito has also posted an introduction to the XNA Game Studio 4.0 Japanese language pack in Japanese on his blog at http://blogs.msdn.com/b/ito/archive/2010/10/21/xna-game-studio-4-0-language-pack-released.aspx.
XNA Game Studio 4.0 Japanese language pack links
Here are some links to help you get started if you want to use the XNA Game Studio 4.0 Japanese language pack:
How to install the XNA Game Studio 4.0 Japanese language pack
You must first install XNA Game Studio 4.0 before installing the Japanese language pack. You can install XNA Game Studio 4.0 by using one of the following installers:
What is included in the XNA Game Studio 4.0 Japanese language pack
The XNA Game Studio 4.0 Japanese language pack provides localized versions of the following XNA Game Studio 4.0 components:
You previously posted lists of command line switches to perform silent and unattended installations of the Visual C++ 2005 redistributable and the Visual C++ 2008 redistributable. How can I perform silent and unattended installations of the Visual C++ 2010 redistributable?
The Visual C++ 2010 redistributable packages (vcredist_x86.exe, vcredist_x64.exe and vcredist_ia64.exe) support the following command line installation options.
The examples below use the file named vcredist_x86.exe, but you can substitute the x64 or ia64 versions of the EXEs with equivalent command lines to achieve the same behavior for them as well.
This option will suppress all UI and perform an install.
<full path>\vcredist_x86.exe /q /norestart For example, if you download vcredist_x86.exe to a folder named c:\vc2010redist, then the command line would look like this: c:\vc2010redist\vcredist_x86.exe /q /norestart
<full path>\vcredist_x86.exe /q /norestart
For example, if you download vcredist_x86.exe to a folder named c:\vc2010redist, then the command line would look like this:
c:\vc2010redist\vcredist_x86.exe /q /norestart
This option will display a progress dialog (but requires no user interaction) and perform an install.
<full path>\vcredist_x86.exe /passive /norestart For example, if you download vcredist_x86.exe to a folder named c:\vc2010redist, then the command line would look like this: c:\vc2010redist\vcredist_x86.exe /passive /norestart
<full path>\vcredist_x86.exe /passive /norestart
c:\vc2010redist\vcredist_x86.exe /passive /norestart
This option will suppress all UI and perform a repair.
<full path>\vcredist_x86.exe /q /repair /norestart For example, if you download vcredist_x86.exe to a folder named c:\vc2010redist, then the command line would look like this: c:\vc2010redist\vcredist_x86.exe /q /repair /norestart
<full path>\vcredist_x86.exe /q /repair /norestart
c:\vc2010redist\vcredist_x86.exe /q /repair /norestart
This option will suppress all UI and perform an uninstall.
<full path>\vcredist_x86.exe /q /uninstall /norestart For example, if you download vcredist_x86.exe to a folder named c:\vc2010redist, then the command line would look like this: c:\vc2010redist\vcredist_x86.exe /q /uninstall /norestart
<full path>\vcredist_x86.exe /q /uninstall /norestart
c:\vc2010redist\vcredist_x86.exe /q /uninstall /norestart
A note about reboots
All of the examples above use the /norestart switch to suppress reboots after the setup process completes. The /norestart switch does not eliminate the need to reboot entirely – it just gives the calling process control over when to schedule the reboot if one is needed due to files being in use during setup. If you run the Visual C++ 2010 redistributable setup and use the /norestart switch, you must check the exit code returned by the setup process and handle it accordingly in the calling process. Here are the possible exit codes:
At the end of last week, the French, German, Italian and Spanish versions of the Windows Phone Developer Tools were released. These versions of WPDT contain localized versions of the developer tools (including XNA Game Studio 4.0 components) and the Windows Phone Emulator. You can only install one language of the Windows Phone Developer Tools on a computer at a time, so if you already have the English version installed and want to use one of these localized versions, you will need to uninstall the English version first.
Here are links that you can use to download and get started using each language version of the Windows Phone Developer Tools.
French Windows Phone Developer Tools links
German Windows Phone Developer Tools links
Italian Windows Phone Developer Tools links
Spanish Windows Phone Developer Tools links
There was an item posted on the XNA Game Studio team blog today that I wanted to link to in order to raise visibility because it helps answer some questions that have been asked frequently since XNA Game Studio 4.0 shipped last month. The post is located at http://blogs.msdn.com/b/xna/archive/2010/10/12/xna-game-studio-4-0-submissions-for-xbox-live-indie-games.aspx, and it provides more detail about the timeframe when the Xbox LIVE Indie Games submission pipeline will start accepting games created with XNA Game Studio 4.0 and when it will stop accepting games created with XNA Game Studio 3.1.
Here is a summary of the information in that post:
If you are just getting started with an Xbox 360 game using XNA Game Studio or have a game in progress that you do not plan to be ready to publish on Xbox LIVE Indie Games by the end of this year, then we recommend starting with XNA Game Studio 4.0 or porting your game to XNA Game Studio 4.0 to prepare for the above changes to the Xbox LIVE Indie Game pipeline.
As always, stay tuned to the XNA Game Studio team blog and the App Hub site for future announcements about the final release date for XNA Game Studio Connect for XNA Game Studio 4.0 and the opening of the Xbox LIVE Indie Games pipeline for XNA Game Studio 4.0 games.