[release/10.0.3xx] Source code updates from dotnet/msbuild#5204
Conversation
Diff: https://github.com/dotnet/msbuild/compare/6ef3f7b7870b0cdecd9773d4c7b3c58f206f554b..3477e49ea400d3fcae00dad9370b20fa88dfd86a From: dotnet/msbuild@6ef3f7b To: dotnet/msbuild@3477e49 [[ commit created by automation ]]
[[ commit created by automation ]]
Adds SDK layout and installer support for the MSBuild apphost, following the same pattern as the Roslyn apphost changes (#3180). Changes: - Define _MSBuildAppHost item in Directory.Build.props - Add CreateMSBuildAppHost target in GenerateLayout.targets (CreateAppHost, COM .tlb copy on Windows, codesign on macOS) - Add MSBuild apphost chmod in ChmodPublishDir and Crossgen targets - Add macOS signing config for MSBuild apphost in Signing.props - Add msbuild-entitlements.plist for macOS codesigning - Add Microsoft.Build.Framework.tlb binary for Windows COM support - Allow .tlb in allowed-vmr-binaries.txt Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
|
@dotnet/msbuild this PR contains changes for installer to distribute AppHost, inspired by #3180 |
4ce982f to
b06eff0
Compare
Diff: https://github.com/dotnet/msbuild/compare/3477e49ea400d3fcae00dad9370b20fa88dfd86a..b481c50980677f430d6f617b3093969267c09713 From: dotnet/msbuild@3477e49 To: dotnet/msbuild@b481c50 [[ commit created by automation ]]
…bc2a-26f2e72cde5f
|
Note PRs from original repository included in this codeflow update: 💡 You may consult the FAQ for more information or tag @dotnet/prodconsvcs for assistance. |
|
Just as a general note: Never force push into a dependency flow PR. This can cause issues with Maestro. |
|
@ViktorHofer The TFM compat warning added in dotnet/msbuild#13187 (eng/packaging.targets) is breaking the SDK build in this codeflow PR on both Linux x64 and Windows x86. What happens: MSBuild 18.6.0-ci packages now include buildTransitive/netcoreapp2.0/*.targets that emit a
Why main is unaffected: On main, Arcade bumped NetMinimum to net10.0 and removed NetToolMinimum. The SDK projects there use $(NetMinimum) = net10.0, which Question: Was this intended to catch a real issue with these packages, or is this a misfire for VMR-intermediate packages? If the latter, the cleanest fix seems to be conditioning the target on '$(DotNetBuild)' != 'true' in packaging.targets (similar to the existing NU5104 suppression in MSBuild's Directory.Build.props), since VMR-produced MSBuild packages are never published to NuGet. Do you think this analysis is relevant and the appropriate path forward? |
|
I will take a look later today. This is a weird situation due to the dual check-in of msbuild. The warnings are appropriate in 11.0 but in 10.0.3xx, dependencies still target net8.0 which conflict with the minimum supported TFM in the msbuild repo. |
Diff: https://github.com/dotnet/msbuild/compare/b481c50980677f430d6f617b3093969267c09713..b93059caee3e3eef947a863966545b65ff8b4834 From: dotnet/msbuild@b481c50 To: dotnet/msbuild@b93059c [[ commit created by automation ]]
|
Note PRs from original repository included in this codeflow update: 💡 You may consult the FAQ for more information or tag @dotnet/prodconsvcs for assistance. |
TryFromMSBuildAppHost and TryFromAppContextBaseDirectory now check
IsRunningInMSBuildExe before using the MSBuild apphost as the current
MSBuild executable. Without this, worker nodes get launched via the
apphost, changing Environment.ProcessPath to the SDK directory where
dotnet is not present, breaking Process.Start("dotnet") resolution
in tasks like VSTestTask.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Diff: https://github.com/dotnet/msbuild/compare/b93059caee3e3eef947a863966545b65ff8b4834..9d58c2fa848d9048e4d947c705c25529af0ea087 From: dotnet/msbuild@b93059c To: dotnet/msbuild@9d58c2f [[ commit created by automation ]]
[[ commit created by automation ]]
|
Note PRs from original repository included in this codeflow update:
💡 You may consult the FAQ for more information or tag @dotnet/prodconsvcs for assistance. |
Diff: https://github.com/dotnet/msbuild/compare/9d58c2fa848d9048e4d947c705c25529af0ea087..0b2773ead1e5f53eee687786dee46c168a876b56 From: dotnet/msbuild@9d58c2f To: dotnet/msbuild@0b2773e [[ commit created by automation ]]
…bc2a-26f2e72cde5f
|
Note PRs from original repository included in this codeflow update: 💡 You may consult the FAQ for more information or tag @dotnet/prodconsvcs for assistance. |
Diff: https://github.com/dotnet/msbuild/compare/0b2773ead1e5f53eee687786dee46c168a876b56..986a951032a2461db8098ae0d57a53a4e27f49a4 From: dotnet/msbuild@0b2773e To: dotnet/msbuild@986a951 [[ commit created by automation ]]
…bc2a-26f2e72cde5f
|
Note PRs from original repository included in this codeflow update: 💡 You may consult the FAQ for more information or tag @dotnet/prodconsvcs for assistance. |
Diff: https://github.com/dotnet/msbuild/compare/986a951032a2461db8098ae0d57a53a4e27f49a4..6500dd278aed2749db445942790934e3c0d8c729 From: dotnet/msbuild@986a951 To: dotnet/msbuild@6500dd2 [[ commit created by automation ]]
|
Note PRs from original repository included in this codeflow update: 💡 You may consult the FAQ for more information or tag @dotnet/prodconsvcs for assistance. |
…ing in binary - Remove checked-in .tlb binary from sdk Layout; generate at build time via tlbexp.exe during net472 build (CreateTypeLib target) - Unified tlbexp.exe resolution: registry-based lookup with hardcoded fallback, works on both desktop and Core MSBuild (no MSBuildRuntimeType branching) - Generate both x86 and x64 type libraries in all builds (the .tlb ships in both Visual Studio and the .NET SDK on Windows) - Enable CreateTlb in VMR Windows builds (DotNetBuildSourceOnly != true) - Include .tlb in Microsoft.Build.Framework NuGet package (lib/net472/) - SDK layout copies .tlb from NuGet package cache with Exists() guard Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…per workaround VSTestTask: Use DOTNET_HOST_PATH environment variable (set by the SDK) to resolve the dotnet host path, with PATH search as fallback. This is the proper fix for the 'dotnet not found' error that occurs when MSBuild runs via the apphost and Environment.ProcessPath changes to the SDK directory. BuildEnvironmentHelper: Revert the IsRunningInMSBuildExe guard in TryFromMSBuildAppHost and the context-aware logic in TryFromAppContextBaseDirectory. These were workarounds for the same issue and are no longer needed now that VSTestTask resolves dotnet properly. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
|
After the final look from @rainersigwald , it's ready to go. |
|
the PR contains installer changes for dotnet/msbuild#12995 |
Note
This is a codeflow update. It may contain both source code changes from
the source repo
as well as dependency updates. Learn more here.
This pull request brings the following source code changes
From https://github.com/dotnet/msbuild
Diff the source with this PR branch