XNA projects fail with error loading Framework 15.1

[roy-t]

I'm getting an error when compiling an XNA Content Project using MSBuild 15. I have no problems when using MSBuild 14.

The error message is:

Error loading pipeline assembly "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0\Microsoft.Build.Framework.dll". XNAVS2017 C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\Microsoft\XNA Game Studio\v4.0\Microsoft.Xna.GameStudio.ContentPipeline.targets 78

This is strange since the file Microsoft.Build.Framework.dll is present in that directory and the MSBuild log seems to indicate the file was located succesfully. So I'm not sure why it won't load.

The fusion log seems to indicate a problem under MSBuild 15, but not under MSBuild 14.
fusion_msbuild14.txt
fusion_msbuild15.txt

To reproduce this problem create an empty XNA Windows Game project and add an existing bitmap file to the content project. (Just to make sure the content project isn't skipped). Then build it using the following parameters:

& 'C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\MSBuild.exe' .\MyXnaProject.sln /p:platform=x86 /p:configuration=Debug
The version of MSBuild that I'm using is

Microsoft (R) Build Engine version 15.1.548.43366

I've attached a log with full diagnostics and a small reproduction project

msbuild.txt
Repo.zip

[roy-t]

I tried to make sense of the fusion logs and I think I've narrowed down the problem.

Version 4.0 of Microsoft.Build.Framework.dll is loaded succesfully

LOG: Attempting download of new URL file:///C:/Program Files (x86)/Reference Assemblies/Microsoft/Framework/.NETFramework/v4.0/Microsoft.Build.Framework.dll.
LOG: Assembly download was successful. Attempting setup of file: C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0\Microsoft.Build.Framework.dll

But then an Assembly Redirect is found:

LOG: Redirect found in application configuration file: 4.0.0.0 redirected to 15.1.0.0.
LOG: Post-policy reference: Microsoft.Build.Framework, Version=15.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a

Finding this new version fails:

Bind result: hr = 0x80070002. The system cannot find the file specified.

The Assembly Redirect is defined in

C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\MSBuild.exe.config

<dependentAssembly>
          <assemblyIdentity name="Microsoft.Build.Framework" culture="neutral" publicKeyToken="b03f5f7f11d50a3a" />
          <bindingRedirect oldVersion="0.0.0.0-99.9.9.9" newVersion="15.1.0.0" />
        </dependentAssembly>

The path to the v15 version of Microsoft.Build.Framework.dll is

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

So I guess the question now is how do I make sure that it can be found?

[roy-t]

I've created a workaround. But I'm not sure if this is the proper way to go.

Open the Developer Command Prompt for VS 2017 as administrator and execute the following commands:

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

This adds the newest version of Microsoft.Build.Framework to the Global Assembly Cache, which allows the correct version of the DLL to be found after the Binding Redirect happens. After this I can build an XNA content project without problems. But I'm pretty sure this is not the ideal way to make this work and I'm not sure if there are any negative implications.

Note that the GAC already contains v14, 4, 3.5, and 2.0 version of Microsoft.Build.Framework, was it an oversight to not add v15? It seems to me this is not an XNA related issue, but that any project referencing an older version of Microsoft.Build.Framework will fail due to this binding redirect.

[rainersigwald]

I agree that that's the proximate cause of the issue.

GACing the Framework assembly will indeed work around the issue, but it scares me for a few reasons. The biggest negative implications I anticipate are around updates to MSBuild/Visual Studio (the version you've GACed will be used, instead of the updated version, so you'll have to manually re-GAC after any update) and around multiple installs of Visual Studio (the GACed version will always be used instead of the right local version).

MSBuild 15 is intentionally not GACed. This is part of the new VS installation process and isolation model that enables faster installation and update and side-by-side installations. This doesn't affect everything that refers to an older version of Framework, because generally the assembly loader will see that the assembly is already loaded and use that. I suspect that the XNA pipeline is using an isolated AppDomain that doesn't set up the right load policy.

[Sarabeth-Jaffe-Microsoft]

@roy-t We're glad you were able to create a work around to fix your issue.

However, please be advised that XNA hasn’t been officially supported in years. The open-source effort, MonoGames, recreates most of what XNA was doing, but the XNA team was disbanded before Xbox One launched.

Also, for reasons @rainersigwald laid out, we do not officially "support" or recommend this workaround.

Thanks,
MSBuild team

[wldevries]

You point out the danger of putting the Microsoft.Build.Framework.dll file in the GAC, because it could break VS when it is updated. Wouldn't this only cause a problem if the version of the dll stays exactly the same? I'm assuming the version of the dll will increase when VS2017 SP1 is released.

[vpenades]

@Sarabeth-Jaffe-Microsoft We are well aware that XNA has been dropped for some years, but there's several big projects around that still require maintenance. We're in the process to move on, but there's clients that refuse to move, but they keep asking for updates and patches, so we have no option than to keep working with the old XNA.

Many legacy XNA projects cannot be ported to MonoGame easily because, although both platforms surface API are equivalent, the content processing pipelines of both frameworks are wildly different, and in some cases are not fully equivalent, specially when handling 3D models, to the point you would require, in many cases, to redo the assets from scratch, and these assets are precisely the most expensive part of our project.

[wldevries]

We are in the exact same situation, MonoGame is fine for multiplatform development but doesn't come close to XNA in terms of features and stability.

@rainersigwald could you explain the dangers of placing Microsoft.Build.Framework.dll in the GAC and is there a blog post that explains the reasoning behind the change in the build tooling?

[SimonDarksideJ]

Any update on this @rainersigwald @roy-t ? Seems to have been closed with no solution?

[wldevries]

silently ignored..

[roy-t]

@DDReaper (Hey Simon ;) ) did you see the workaround posted in this thread? Here is a full explanation: https://gist.github.com/roy-t/2f089414078bf7218350e8c847951255

[SimonDarksideJ]

Will check it out.
Seems the VS2017 plugin for MSXNA seems to have stalled at the mo. With the demise of CodePlex, this is a slight worry :S

[roy-t]

Hmm my fix relies on the 2015 version of MSXNA, the VS2017 version doesn't seem to do anything useful. Oh well, luckily I've switched to Monogame for my personal projects. At work though we rely on XNA with 20+ projects.. I'll make sure we have a backed up copy of MSXNA2015 there before codeplex goes down. :/

[SimonDarksideJ]

Same here, if it does go. Sure enough I'll be creating another new repository to keep it in the running.
I use it as a huge source of reference, given how close MonoGame and XNA are.

I'm all MonoGame for new projects but a huge amount of XNA content still exists which can be utilised for MG.

I've already archived the entire XNAGameStudio educational library (https://github.com/DDReaper/XNAGameStudio) and in the process of MonoGame'fying it all. Also now 20% through archiving all of Ziggywares content to the site and there are some real gems there.