[dotnet] Don't overwrite any existing value for DOTNET_DiagnosticPorts when computed through our build logic. #23993
Conversation
…s when computed through our build logic. Until now, people set the 'DOTNET_DiagnosticPorts' environment variable at launch/runtime to profile or trace an app. When we added support for setting specific MSBuild properties to enable diagnostics (DiagnosticsAddress, DiagnosticsSuspend, etc.), we end up unconditionally setting the DOTNET_DiagnosticPorts environment variable, effectively overwriting any value specified by customers when launching the app. This meant that existing (and fully functioning) profiling/tracing workflows would only work if they set the DOTNET_DiagnosticPorts variable to the defaults we have. Fix this by allowing overriding DOTNET_DiagnosticPorts variable at launch/runtime.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
✅ [CI Build #5937332] Build passed (Build packages) ✅Pipeline on Agent |
✅ [PR Build #5937332] Build passed (Detect API changes) ✅Pipeline on Agent |
This comment has been minimized.
This comment has been minimized.
✅ [CI Build #5937332] Build passed (Build macOS tests) ✅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 |
💻 [CI Build #5937332] Tests on macOS X64 - Mac Sonoma (14) passed 💻✅ All tests on macOS X64 - Mac Sonoma (14) passed. Pipeline on Agent |
💻 [CI Build #5937332] Tests on macOS arm64 - Mac Sequoia (15) passed 💻✅ All tests on macOS arm64 - Mac Sequoia (15) passed. Pipeline on Agent |
💻 [CI Build #5937332] Tests on macOS M1 - Mac Monterey (12) passed 💻✅ All tests on macOS M1 - Mac Monterey (12) passed. Pipeline on Agent |
💻 [CI Build #5937332] Tests on macOS M1 - Mac Ventura (13) passed 💻✅ All tests on macOS M1 - Mac Ventura (13) passed. Pipeline on Agent |
This comment has been minimized.
This comment has been minimized.
💻 [CI Build #5937332] Tests on macOS arm64 - Mac Tahoe (26) passed 💻✅ All tests on macOS arm64 - Mac Tahoe (26) passed. Pipeline on Agent |
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.
This comment has been minimized.
This comment has been minimized.
🚀 [CI Build #5937332] Test results 🚀Test results✅ All tests passed on VSTS: test results. 🎉 All 128 tests passed 🎉 Tests counts✅ cecil: All 1 tests passed. Html Report (VSDrops) Download Pipeline on Agent |
rolfbjarne
deleted the
dev/rolf/do-not-overwrite-DOTNET_DiagnosticPorts
branch
…NET_DiagnosticPorts when computed through our build logic. (#23998) Until now, people set the 'DOTNET_DiagnosticPorts' environment variable at launch/runtime to profile or trace an app. When we added support for setting specific MSBuild properties to enable diagnostics (DiagnosticsAddress, DiagnosticsSuspend, etc.), we end up unconditionally setting the DOTNET_DiagnosticPorts environment variable, effectively overwriting any value specified by customers when launching the app. This meant that existing (and fully functioning) profiling/tracing workflows would only work if they set the DOTNET_DiagnosticPorts variable to the defaults we have. Fix this by allowing overriding DOTNET_DiagnosticPorts variable at launch/runtime. Backport of #23993.
Until now, people set the 'DOTNET_DiagnosticPorts' environment variable at
launch/runtime to profile or trace an app.
When we added support for setting specific MSBuild properties to enable
diagnostics (DiagnosticsAddress, DiagnosticsSuspend, etc.), we end up
unconditionally setting the DOTNET_DiagnosticPorts environment variable,
effectively overwriting any value specified by customers when launching the
app.
This meant that existing (and fully functioning) profiling/tracing workflows
would only work if they set the DOTNET_DiagnosticPorts variable to the
defaults we have.
Fix this by allowing overriding DOTNET_DiagnosticPorts variable at launch/runtime.