[main] Source code updates from dotnet/msbuild#5183
[main] Source code updates from dotnet/msbuild#5183dotnet-maestro[bot] merged 16 commits intomainfrom
Conversation
Diff: https://github.com/dotnet/msbuild/compare/414f0acf7486ff8b4887ddbba5717b030c2f92a3..98231a0f9d8ee91c0a974d20375d17708958a598 From: dotnet/msbuild@414f0ac To: dotnet/msbuild@98231a0 [[ 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/98231a0f9d8ee91c0a974d20375d17708958a598..3477e49ea400d3fcae00dad9370b20fa88dfd86a From: dotnet/msbuild@98231a0 To: dotnet/msbuild@3477e49 [[ 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. |
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>
@YuliiaKovalova I'd like to hear more about this. Not creating the apphost when building the SDK from source creates a difference between the MSFT built SDK and the source-built one (Unix distros). We try to avoid any of these differences whenever possible. Please provide more details on why this was necessary. |
7f1f3b0 to
3153cc7
Compare
|
Out of curiosity, why does 3153cc7 suggest host package isn't available when msbuild explicitly depends on runtime (which builds the host package): dotnet/repo-projects/msbuild.proj Line 13 in c722a3a |
|
Right, the (non-portable distro specific) host package is available in SB. |
you have right, I am investigating it more. |
454ddd0 to
f083f19
Compare
Diff: https://github.com/dotnet/msbuild/compare/3477e49ea400d3fcae00dad9370b20fa88dfd86a..b481c50980677f430d6f617b3093969267c09713 From: dotnet/msbuild@3477e49 To: dotnet/msbuild@b481c50 [[ 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/b481c50980677f430d6f617b3093969267c09713..0b2773ead1e5f53eee687786dee46c168a876b56 From: dotnet/msbuild@b481c50 To: dotnet/msbuild@0b2773e [[ 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. |
|
the PR is green now, can we merge it? |
could we please hold it till the end of the day - I want to check if we can avoid shipping .tlb + fix for VSTestTask (i run my experiments in a separate branch) |
Diff: https://github.com/dotnet/msbuild/compare/0b2773ead1e5f53eee687786dee46c168a876b56..6500dd278aed2749db445942790934e3c0d8c729 From: dotnet/msbuild@0b2773e 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>
|
the same here: After the final look from @rainersigwald , it's ready to go. |
|
the PR contains installer changes for dotnet/msbuild#12995 |
MSBuild's apphost support (dotnet/msbuild#13175) requires DOTNET_HOST_PATH to resolve DOTNET_ROOT when launching out-of-proc task hosts for TaskHostFactory tasks (e.g. ComputeWasmBuildAssets, ComputeManagedAssemblies). The MSBuild apphost is now created in the SDK layout (dotnet/dotnet#5183), so ResolveAppHostOrFallback takes the apphost code path. It calls CreateDotnetRootEnvironmentOverrides which derives DOTNET_ROOT from DOTNET_HOST_PATH. While the dotnet CLI sets this internally, explicitly providing it in the test environment ensures it is available for the task host subprocess launch. Also enable MSBUILDDEBUGCOMM tracing to capture handshake details for diagnosing any remaining task host connection issues. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
MSBuild's apphost support (dotnet/msbuild#13175) requires DOTNET_HOST_PATH to resolve DOTNET_ROOT when launching out-of-proc task hosts for TaskHostFactory tasks (e.g. ComputeWasmBuildAssets, ComputeManagedAssemblies). The MSBuild apphost is now created in the SDK layout (dotnet/dotnet#5183), so ResolveAppHostOrFallback takes the apphost code path. It calls CreateDotnetRootEnvironmentOverrides which derives DOTNET_ROOT from DOTNET_HOST_PATH. While the dotnet CLI sets this internally, explicitly providing it in the test environment ensures it is available for the task host subprocess launch. Diagnostics added: - DOTNET_HOST_PATH set in test environment variables - MSBUILDDEBUGCOMM=1 for node communication tracing - MSBuildDebugEngine=1 with MSBUILDDEBUGPATH for trace file output - SDK layout dump in AoT_Publish test to verify MSBuild apphost presence Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
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