Install XNA 4.0 under Microsoft Visual Studio 2017

xna4_vs2017.md

This guide will provide you with a workaround for using XNA in Visual Studio 2017. This will solve problems with the target files and Microsoft.Build.Framework.dll such as: Error loading pipeline assembly "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0\Microsoft.Build.Framework.dll"

1. Download a modified version of the XNA vsix: https://mxa.codeplex.com/
2. Unzip XNA Game Studio 4.0.vsix and replace the <Installation /> tag in extension.vsixmanifest with this:

 <Installation InstalledByMsi="false">
    <InstallationTarget Version="[12.0,16.0)" Id="Microsoft.VisualStudio.VSWinDesktopExpress" />
    <InstallationTarget Version="[12.0,16.0)" Id="Microsoft.VisualStudio.Pro" />
    <InstallationTarget Version="[12.0,16.0)" Id="Microsoft.VisualStudio.Premium" />
    <InstallationTarget Version="[12.0,16.0)" Id="Microsoft.VisualStudio.Ultimate" />
    <InstallationTarget Version="[14.0,16.0)" Id="Microsoft.VisualStudio.Community" />
    <InstallationTarget Version="[14.0,16.0)" Id="Microsoft.VisualStudio.Enterprise" />
  </Installation>

3. Place everything in a zip file again and change the extension to vsix. Now run the the vsix file. It should give a warning message but other than that install for VS2017 without problems.

4. Copy everything from C:\Program Files (x86)\MSBuild\Microsoft\XNA Game Studio to C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\Microsoft\XNA Game Studio

5. Open the Visual Studio 2017 developer command prompt by searching for Developer command prompt for VS 2017 as administrator and execute the following code: (this will add the new version of Microsoft.Build.Framework to the Global Assembly Cache).

cd C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin
gacutil /i Microsoft.Build.Framework.dll

Note that the bug is tracked here: dotnet/msbuild#1831

After this you should be able to work with XNA in Visual Studio 2017 without problems. Remember that you can upgrade the .Net version XNA uses by manually editing the csproj files in notepad :).

• Roy Triesscheijn @roytries http://roy-t.nl

Oh, wow, I commented here, my bad, I didn't mean comment on this one haha, @isral commented on my one here, I had a massive derp when I wrote my reply here here thinking I was sure that I already replied once, I guess that answers that humdinger.

The MXA installs for installing XNA Game Studio are still on the XNA Game Studio Archive here
https://github.com/SimonDarksideJ/XNAGameStudio/wiki/GettingStarted
There are still only catalogued up to the 2017 version, but it's not that hard to unpack the MSIX installers and update them to newer versions (seen it working in VS2019) but the Visual Studio Team are deprecating older features that the XNA GS depends on as far as I know, so the better route is to still use the versions compatible with these installers for accessing XNA content.

The archive is still slowly updating XNA content to MonoGame, but it's slow progress with only one hand on the wheel ;D

Many thanks for this guide.

My project can't resolve a few classes from the Microsoft.Xna.Framework.Audio package, particularly Cue, AudioEngine, WaveBank and similar. I've poked around and it looks like they're not in the DLL? I'm not really very experienced in C# or Visual Studio, so I'm probably missing something obvious. I'm utterly confused as to why half the contents of the package would be missing!

Any help would be most gratefully received. I'm trying to resurrect an old XNA 3.0 project. I figured that I should try getting it to compile under XNA 4.0 first, and then think about porting it to Mono/FNA. It's been a bit of an epic journey, as I'm a Mac user and have already spent the day faffing about with Bootcamp so I can install Windows :)

D'oh - I was being a twazzock and not reading things properly. I mistakenly believed that, for example, Microsoft.Xna.Framework.Audio.Cue class would be in the Microsoft.Xna.Framework.Audio assembly, and not Microsoft.Xna.Framework.Xact. Probably a rookie's mistake, but it seems that package names and assembly names do not need to match :)