Document hangdump known issues on macos #50346
Conversation
| - Apply a workaround similar to the following: | ||
|
|
||
| ```xml | ||
| <Target Name="WorkaroundMacOSDumpIssue" AfterTargets="Build" Condition="$([MSBuild]::IsOSPlatform('OSX')) AND '$(UseAppHost)' != 'false' AND '$(OutputType)' == 'Exe' AND '$(TargetFramework)' != '' AND '$(RunCommand)' != '' AND '$(RunCommand)' != 'dotnet'" AND '$(IsTestingPlatformApplication)'=='true'> |
There was a problem hiding this comment.
@JanKrivanek @YuliiaKovalova @rainersigwald Please review this from build incrementality point of view. Can this cause issues for incremental builds?
There was a problem hiding this comment.
Pull request overview
This PR documents known issues with generating hang dumps on macOS in the Microsoft Testing Platform Extensions documentation. The content addresses authentication popup issues that prevent dump generation in CI environments and provides two workarounds.
Key Changes
- Added a "Considerations for macOS" section explaining dump generation authentication issues
- Provided two workaround options: disabling UseAppHost or applying code signing with entitlements
- Included complete MSBuild target and plist configuration examples
docs/core/testing/microsoft-testing-platform-extensions-diagnostics.md
Outdated
Show resolved
Hide resolved
| - Set `UseAppHost` MSBuild property to false, which will cause the managed assembly to run under `dotnet` instead of the apphost executable. However, this doesn't work for xunit.v3. See [xunit/xunit#3432 GitHub issues](https://github.com/xunit/xunit/issues/3432). | ||
| - Apply a workaround similar to the following: |
There was a problem hiding this comment.
The list items need periods at the end since they contain complete sentences with more than three words. Both bullet points should end with a period according to the Markdown style guidelines.
| Taking dumps when running on macOS can be problematic. If you found that a dump has started to be taken, but never finishes, in CI environments where you don't have direct access to the machine, this most likely means that macOS showed a popup asking for authentication and is waiting for you to type password, which is not feasible to do in such environments. The issue might also manifest as an error similar to the following: | ||
|
|
||
| ```output | ||
| [createdump] This failure may be because createdump or the application is not properly signed and entitled. |
There was a problem hiding this comment.
Missing Oxford comma in the list. Change "signed and entitled" to "signed, and entitled" according to the mandatory Oxford comma rule in the Markdown style guidelines.
docs/core/testing/microsoft-testing-platform-extensions-diagnostics.md
Outdated
Show resolved
Hide resolved
| </plist> | ||
| ``` | ||
|
|
||
| The MSBuild target above can be placed in Directory.Build.targets so that it applies to all projects. |
There was a problem hiding this comment.
The sentence "The MSBuild target above can be placed in Directory.Build.targets so that it applies to all projects." is more than three words and should end with a period according to the Markdown style guidelines.
docs/core/testing/microsoft-testing-platform-extensions-diagnostics.md
Outdated
Show resolved
Hide resolved
| <key>com.apple.security.cs.allow-jit</key> | ||
| <true/> | ||
| <key>com.apple.security.cs.allow-dyld-environment-variables</key> | ||
| <true/> | ||
| <key>com.apple.security.cs.disable-library-validation</key> | ||
| <true/> | ||
| <key>com.apple.security.cs.debugger</key> | ||
| <true/> | ||
| <key>com.apple.security.get-task-allow</key> | ||
| <true/> | ||
| </dict> |
There was a problem hiding this comment.
The suggested entitlements in mtp-test-entitlements.plist (com.apple.security.get-task-allow, com.apple.security.cs.debugger, com.apple.security.cs.disable-library-validation, com.apple.security.cs.allow-dyld-environment-variables, com.apple.security.cs.allow-jit) significantly weaken macOS code signing protections; if applied broadly (as later suggested via Directory.Build.targets), this can enable debugging and task access on production binaries, facilitating code injection and tampering. An attacker or unprivileged process could leverage these entitlements to attach, modify, or bypass library validation in production environments. Limit this workaround strictly to test/debug builds (e.g., add Condition="'$(Configuration)' == 'Debug' AND '$(IsTestingPlatformApplication)'=='true'"), avoid com.apple.security.get-task-allow and com.apple.security.cs.debugger for any release builds, and ensure it is not placed in Directory.Build.targets for projects that produce deployable artifacts.
There was a problem hiding this comment.
@blowdart Please take a look. The condition IsTestingPlatformApplication should limit the workaround only to test applications. Is there any security considerations to document more clearly here?
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
| To work around this, there are two options: | ||
|
|
||
| - Set `UseAppHost` MSBuild property to false, which will cause the managed assembly to run under `dotnet` instead of the apphost executable. However, this doesn't work for xunit.v3. See [xunit/xunit#3432 GitHub issue](https://github.com/xunit/xunit/issues/3432). | ||
| - Apply a workaround similar to the following: |
There was a problem hiding this comment.
Would it be a simpler workaround to force UseAppHost=false (e.g. by passing it to msbuild as /p:UseAppHost=false) so that the xunit block does not kick in? Or is there something that actually does not work in xunit3 + MTP without apphost?
There was a problem hiding this comment.
xunit.v3 blocks completely the ability to set UseAppHost to false.
There was a problem hiding this comment.
If you pass /p:UseAppHost=false on the command line, they cannot override it - the line in xunit targets that sets it to true is going to be ignored,
There was a problem hiding this comment.
@jkotas xunit doesn't set it to true, they produce an error when it's set to false.
Internal previews