search

dotnet / msbuild

The Microsoft Build Engine (MSBuild) is the build platform for .NET and Visual Studio.
https://docs.microsoft.com/visualstudio/msbuild/msbuild
MIT License
5.23k stars 1.35k forks source link

“MSB0001: Internal MSBuild Error: Already registered for build-time” in Visual Studio 15.8.0 #3610

Closed iainnicol closed 6 years ago

iainnicol commented 6 years ago

Steps to reproduce

  1. Check out minimal reproducible example from the repository https://github.com/iainnicol/ReproForMsbuildAlreadyRegisteredForBuildTime
  2. Open the .sln inside version 15.8.0 of the Visual Studio GUI
  3. Build menu -> Build Solution

The key part of this minimal example is that the solution has one C# project (either old or new style csproj), plus two F# projects (old style fsproj). By "new style" I mean using the modern MSBuild SDK, and by old style I mean the format which predates that.

Expected behavior

Builds successfully.

Actual behavior

Build fails due to an internal MSBuild Error:

1>------ Build started: Project: fsharp1, Configuration: Debug Any CPU ------
2>------ Build started: Project: fsharp2, Configuration: Debug Any CPU ------
2>Unhandled Exception:MSB0001: Internal MSBuild Error: Already registered for build-time.
2>Error: MSB0001: Internal MSBuild Error: Already registered for build-time.
3>------ Build started: Project: csharp, Configuration: Debug Any CPU ------
3>  csharp -> C:\git\ReproForMsbuildAlreadyRegisteredForBuildTime\csharp\bin\Debug\csharp.dll
1>      fsharp1 -> C:\git\ReproForMsbuildAlreadyRegisteredForBuildTime\fsharp1\bin\Debug\fsharp1.dll
========== Build: 2 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

Note that subsequent builds may succeed, so you may need to run

git clean -dfx

to reproduce again.

Environment data

Windows 10, version 1803, OS Build 17134.191.

Visual Studio v15.8.0. The issue is not present in v15.7.x.

Other information

Weirdly, running msbuild from a Visual Studio command line (VsDevCmd.bat) is successful. I only see the failure inside the Visual Studio GUI.

Finally, there is a thread Visual Studio forum, where others have encountered the issue.

simendsjo commented 6 years ago

A comment on the VS forum (https://developercommunity.visualstudio.com/comments/311939/view.html):

Looking at MSBuild code, seems to be a threading bug. I reduced concurrent builds from 8 to 1 to work around this issue

This seems to work for me too.

nbevans commented 6 years ago

Reducing from 2 to 1 under VS > Options > Projects and Solutions > Build and Run fixed this for me.

jongleur1983 commented 6 years ago

Reducing to 1 works around this issue for me as well - but down from 8 to 1 that's an inacceptable performance regression, so it's not acceptable as a solution for me.

simendsjo commented 6 years ago

Reducing to 1 works around this issue for me as well - but down from 8 to 1 that's an inacceptable performance regression, so it's not acceptable as a solution for me.

Compiling

AndyGerlicher commented 6 years ago

Turns out this isn't an MSBuild issue. Progress should be tracked here: https://github.com/Microsoft/visualfsharp/issues/5504

gchernis commented 6 years ago

@AndyGerlicher If you have spare time, could you elaborate how the corrected logic takes care of the intermittent behavior on multi-core?

cdmihai commented 6 years ago

@gchernis When the F# project system in VS was doing parallel builds, sometimes it reused the same msbuild logger for multiple parallel builds (not a data race), which caused a runtime precondition check in msbuild to fail. The fix is to not reuse loggers for parallel builds.

gchernis commented 6 years ago

Just tried the nightly build of Visual F#. My solution builds fine with 16 cores concurrently. https://dotnet.myget.org/feed/fsharp/package/vsix/VisualFSharp/15.8.20180906.2