[dotnet] Remove DOTNET_STARTUP_HOOKS 'env' workaround. Fixes #25799. - #26008
Conversation
PR #25738 added a temporary workaround in Microsoft.Sdk.Desktop.targets for sandboxed Mac Catalyst apps: when 'dotnet watch' set DOTNET_STARTUP_HOOKS to a path outside the app sandbox, we overrode RunCommand to 'env' to force the container-relative DOTNET_STARTUP_HOOKS value onto the launched process, because the SDK didn't honor changes made to the @(RuntimeEnvironmentVariable) item group after ComputeRunArguments. dotnet/sdk#54922 now honors those item-group changes for projects with the RuntimeEnvironmentVariableSupport capability (which .NET for iOS/Mac Catalyst projects set), so the 'env' override is redundant. The targets still copy the startup hook into the sandbox container and re-point the DOTNET_STARTUP_HOOKS @(RuntimeEnvironmentVariable) item at it; the SDK applies that when launching. Verified the SDK pinned in global.json (11.0.100-preview.7.26358.120) contains the fix (HasRuntimeEnvironmentVariableSupport / ReadFromItems). Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
There was a problem hiding this comment.
Pull request overview
Removes a temporary MSBuild workaround in the desktop run pipeline now that the pinned .NET SDK honors post-ComputeRunArguments updates to @(RuntimeEnvironmentVariable) for projects with the RuntimeEnvironmentVariableSupport capability (used by Apple platforms in this repo).
Changes:
- Removed the
RunCommand=env/RunArguments="DOTNET_STARTUP_HOOKS=..."override previously used forRunWithOpen=false. - Kept the existing logic that copies the startup hook into the Mac Catalyst sandbox container and repoints
DOTNET_STARTUP_HOOKSvia@(RuntimeEnvironmentVariable).
This comment has been minimized.
This comment has been minimized.
✅ [PR Build #42ad6c3] Build passed (Detect API changes) ✅Pipeline on Agent |
✅ API diff for current PR / commitNET (empty diffs)✅ API diff vs stableNET (empty diffs)ℹ️ Generator diffGenerator Diff: vsdrops (html) vsdrops (raw diff) gist (raw diff) - Please review changes) Pipeline on Agent |
✅ [PR Build #42ad6c3] Build passed (Build packages) ✅Pipeline on Agent |
✅ [PR Build #42ad6c3] Build passed (Build macOS tests) ✅Pipeline on Agent |
🚀 [CI Build #42ad6c3] Test results 🚀Test results✅ All tests passed on VSTS: test results. 🎉 All 256 tests passed 🎉 Tests counts✅ assembly-processing: All 1 tests passed. Html Report (VSDrops) Download macOS tests✅ Tests on macOS Sonoma (14): All 5 tests passed. Html Report (VSDrops) Download Linux Build VerificationPipeline on Agent |
PR #25738 added a temporary workaround in
Microsoft.Sdk.Desktop.targetsforsandboxed Mac Catalyst apps: when
dotnet watchsetDOTNET_STARTUP_HOOKSto apath outside the app sandbox, we overrode
RunCommandtoenvto force thecontainer-relative
DOTNET_STARTUP_HOOKSvalue onto the launched process,because the SDK didn't honor changes made to the
@(RuntimeEnvironmentVariable)item group after
ComputeRunArguments.dotnet/sdk#54922 now honors those
item-group changes for projects with the
RuntimeEnvironmentVariableSupportcapability (which .NET for iOS / Mac Catalyst projects set), so the
envoverride is redundant. The targets still copy the startup hook into the sandbox
container and re-point the
DOTNET_STARTUP_HOOKS@(RuntimeEnvironmentVariable)item at it; the SDK applies that when launching.
Verified the SDK pinned in
global.json(11.0.100-preview.7.26358.120)contains the fix (
HasRuntimeEnvironmentVariableSupport/ReadFromItems).Fixes #25799
🤖 Pull request created by Copilot