[release/7.0-rc1] net7.0 + net6.0 workload multitargeting changes#74018
[release/7.0-rc1] net7.0 + net6.0 workload multitargeting changes#74018lewing merged 46 commits intorelease/7.0-rc1from
Conversation
|
Tagging subscribers to this area: @dotnet/ncl Issue Detailsnull
|
|
Tagging subscribers to this area: @directhex Issue Detailsnull
|
…7 but NOT in 6. Dotnet workload install wasm-tools-net6 should install a different set of components than wasm-tools
d9cd98e to
7ad680e
Compare
Don't use **FromWorkload** for pack versions because it doesn't understand the name aliasing we have to use with runtime packs
0dc04d2 to
3af277a
Compare
3af277a to
4ac41be
Compare
|
/azp run runtime, runtime-staging |
|
Azure Pipelines successfully started running 2 pipeline(s). |
When running a fresh build with `dotnet build`, the first one works
fine. But all the subsequent builds fail with no info in the logs at
all.
```
$ /workspaces/runtime/artifacts/bin/dotnet-net7/dotnet build
MSBuild version 17.4.0-preview-22413-01+f0a66ec43 for .NET
Build FAILED.
0 Warning(s)
0 Error(s)
```
And it seems to be related to msbuild nodes, so disable NodeReuse.
…ng-net7-workload-changes
it appears to be looking up the runtime pack in the packs directory without a version on the pack
|
|
@marcpopMSFT could it be dotnet/sdk@0bc1ff8 |
|
Found the issue on our side, the tests were including a bunch of outdated logic that was breaking things |
|
Approved, assuming the CI is green. |
| // second, and subsequent builds fail without any details | ||
| // in the logs | ||
| EnvVars["DOTNET_CLI_DO_NOT_USE_MSBUILD_SERVER"] = "1"; | ||
| DefaultBuildArgs += " /nr:false"; |
There was a problem hiding this comment.
do we have an issue filed for this?
There was a problem hiding this comment.
It might be related to this one: dotnet/sdk#26965 (comment)
But with newer builds of the SDK, I was able to take out this workaround.
No description provided.