-
Notifications
You must be signed in to change notification settings - Fork 1k
MSBuild 15.7.124 for 2.1.3xx #8884
MSBuild 15.7.124 for 2.1.3xx #8884
Conversation
|
Should this go in 15.7 (release/2.1.2xx) as well? Or there we should maintain 108? |
|
@dotnet-bot test this please (Forgot to make sure our packages were pushed to MyGet before starting this, sorry) |
|
@dotnet-bot Test CentOS7.1 x64 Debug Build |
|
@rainersigwald @dsplaisted there is some regression here affecting windows only. There are two tests who have been failing complaining about a direct reference to M.NC.App. Can you guys check? It is happening on the other msbuild insertion on 2.1.2xx as well. |
|
The actual test failure is that the output doesn't contain strings such as |
c6d5dfa to
fc97cd5
Compare
|
The failure is due to microsoft/vstest#1503. Basically, the test infrastructure assumed that writes to stdout from the test-runner process would be piped all the way out through the top-level There's a workaround: set |
|
I see a couple of options:
|
Work around microsoft/vstest#1503 by using the MSBuild escape hatch variable MSBUILDENSURESTDOUTFORTASKPROCESSES and ensuring that tests don't run in a disconnected MSBuild process by passing /nr:false.
fc97cd5 to
d98928e
Compare
|
Just pushed a change that goes with option 3: a new escape hatch + opting into it here. It won't work until dotnet/msbuild#3130 is merged + packaged, but is that something you're amenable to @livarcocc? |
|
this does work e2e, by the way (manually injected new MSBuild into CLI built from this CL): |
|
The updated MSBuild has an updated NuGet reference in the resolver. Had to pull in the NuGet insertion that went into 2.1.2xx to match MSBuild's assembly version to avoid a crossgen failure. |
|
@dotnet-bot test Windows_NT_ES x64 Debug Build please |
Supersedes #8854.
This version has dotnet/msbuild#3126, which should resolve the TF problems from #8854.