Closed bchavez closed 6 years ago
Just a quick update on this for anyone listening:
Following this comment https://github.com/dotnet/sdk/issues/739#issuecomment-275803656, I was able to unblock MS Build by disabling multi-proc builds with adding the switch /m:1
/maxcpucount = 1.
This MS Build bug is even more crazy because MSDN docs say:
If you don't include this switch, the default value is 1.
... but it doesn't seem like it. :confused:
:hourglass_flowing_sand: :mag: "But I still haven't found what I'm for..."
Is there a reason you're not building the .sln directly, and are instead building each project individually?
The TeamCity command line includes
/p:OutputPath="C:\TeamCity\buildAgent\work\141b16321533f9d0\__compile\Bogus.Healthcare\msb_build"
Are you setting that as part of your build customization, or is TeamCity doing it automatically?
Setting OutputPath
is dangerous. It's a project-level setting and each of the TargetFrameworks needs a unique one, but this explicitly sets them to all be the same. Another symptom of this is that you're overwriting the output. From the log you shared:
Bogus.Healthcare -> C:\TeamCity\buildAgent\work\141b16321533f9d0\__compile\Bogus.Healthcare\msb_build\Bogus.Healthcare.dll
...
Bogus.Healthcare -> C:\TeamCity\buildAgent\work\141b16321533f9d0\__compile\Bogus.Healthcare\msb_build\Bogus.Healthcare.dll
The first one is net40; the second is netstandard2.0. It'd overwrite with the 1.3 version too, but the build failed before it tried.
Following this comment #739 (comment), I was able to unblock MS Build by disabling multi-proc builds with adding the switch /m:1 /maxcpucount = 1.
This MS Build bug is even more crazy because MSDN docs say:
If you don't include this switch, the default value is 1.
... but it doesn't seem like it. 😕
There's a /m
(= use as many processors as you have) in your TeamCity command line. I'd guess TeamCity adds it by default; there's probably a configuration checkbox for it.
Hey @rainersigwald ,
Thanks so much for your help. I've been in the weeds with this issue so much I lost the forest for the trees. I didn't realize setting OutputPath
was dangerous until now. What you said makes perfect sense.
I guess the main thing that mislead me into this trap was the following F# FAKE MSBuildReleaseExt
call:
!! Projects.SolutionFile
|> MSBuildReleaseExt null buildProps "Build"
|> Log "AppBuild-Output: "
Originally, I had an OutputPath
set in place of the null
parameter. It just seemed unnatural to pass null
for the build output. I realize now passing null
is the proper way to invoke MS Build without overriding the OutputPath
.
Everything is building successfully without errors. :sunglasses:
Thank you again for your help! Brian
:zap: :runner: "I was struck by lighting. Walkin' down the street..."
In my situation, the reason for the problem was, that there has been different LangVersion settings within the several project files.
Hello.
I've been stuck on a really bad MS Build error for a few days now. Kinda at a loss as to why MS Build is having a hard time building my projects. My issue seems eerily similar to #545 and #739. Google isn't any help either. :desert:
I have a SLN file that contains:
Bogus.Healthcare
.NET Core Assembly project. Multi-targeting:<TargetFrameworks>net40;netstandard1.3;netstandard2.0</TargetFrameworks>
Bogus.Text
.NET Core Assembly project. Multi-targeting:<TargetFrameworks>net40;netstandard1.3;netstandard2.0</TargetFrameworks>
Bogus.Premium.Tests
xUnit project referencing the projects above.Bogus.Tools.Analyzer
.NET Analyzer Project. Single-targeting:<TargetFramework>netstandard1.3</TargetFramework>
(No direct dependency onBogus.Healthcare
)Bogus.Tools.Analyzer.Test
.NET Analyzer MS Test Project that referencesBogus.Tools.Analyzer
(Again, no direct dependency onBogus.Healtchare
)Bogus.Tools.Analyzer.Vsix
Visual Studio Analyzer package project that does referenceBogus.Tools.Analyzer
.The very first project MS Build attempts to build is
Bogus.Healthcare
. I'm using F# FAKE that calls into MS Build to compile everything on a CI (TeamCity) server. TeamCity server starts the build with the following command line:But for some weird reason, I get the following error.
This build fails reliably, every time on my private CI TeamCity server. I can also sometimes get this build error on my development machine.
Thanks a bunch, Brian
:dizzy: :boom: Chaos Chaos - Do You Feel It?
Version Info