New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

XNA projects fail with error loading Framework 15.1 #1831

Closed
roy-t opened this Issue Mar 9, 2017 · 13 comments

Comments

Projects
None yet
6 participants
@roy-t

roy-t commented Mar 9, 2017

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

This comment has been minimized.

Show comment
Hide comment
@roy-t

roy-t Mar 10, 2017

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 commented Mar 10, 2017

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 roy-t changed the title from Error loading pipeline assembly to Binding redirect for Microsoft.Build.Framework 4.0 -> 15.1 fails Mar 10, 2017

@roy-t

This comment has been minimized.

Show comment
Hide comment
@roy-t

roy-t Mar 10, 2017

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.

roy-t commented Mar 10, 2017

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

This comment has been minimized.

Show comment
Hide comment
@rainersigwald

rainersigwald Mar 10, 2017

Contributor

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.

Contributor

rainersigwald commented Mar 10, 2017

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

This comment has been minimized.

Show comment
Hide comment
@Sarabeth-Jaffe-Microsoft

Sarabeth-Jaffe-Microsoft Mar 10, 2017

Contributor

@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

Contributor

Sarabeth-Jaffe-Microsoft commented Mar 10, 2017

@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

@rainersigwald rainersigwald changed the title from Binding redirect for Microsoft.Build.Framework 4.0 -> 15.1 fails to XNA projects fail with error loading Framework 15.1 Mar 13, 2017

@wldevries

This comment has been minimized.

Show comment
Hide comment
@wldevries

wldevries Mar 16, 2017

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.

wldevries commented Mar 16, 2017

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

This comment has been minimized.

Show comment
Hide comment
@vpenades

vpenades Apr 6, 2017

@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.

vpenades commented Apr 6, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@wldevries

wldevries Apr 11, 2017

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?

wldevries commented Apr 11, 2017

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

This comment has been minimized.

Show comment
Hide comment
@SimonDarksideJ

SimonDarksideJ Jun 8, 2017

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

SimonDarksideJ commented Jun 8, 2017

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

@wldevries

This comment has been minimized.

Show comment
Hide comment
@wldevries

wldevries Jun 8, 2017

silently ignored..

wldevries commented Jun 8, 2017

silently ignored..

@roy-t

This comment has been minimized.

Show comment
Hide comment
@roy-t

roy-t Jun 8, 2017

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

roy-t commented Jun 8, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@SimonDarksideJ

SimonDarksideJ Jun 8, 2017

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

SimonDarksideJ commented Jun 8, 2017

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

This comment has been minimized.

Show comment
Hide comment
@roy-t

roy-t Jun 8, 2017

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. :/

roy-t commented Jun 8, 2017

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

This comment has been minimized.

Show comment
Hide comment
@SimonDarksideJ

SimonDarksideJ Jun 8, 2017

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.

SimonDarksideJ commented Jun 8, 2017

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment