[wasi] System.Private.Xml.Tests cannot find TestFiles test data

[lewing]

Description

On CoreCLR WASI, most of System.Private.Xml.Tests fails because the test data files are not found:

System.TypeInitializationException : The type initializer for 'System.Xml.Tests.XsltApiTestCaseBase' threw an exception.
---- System.IO.FileNotFoundException : Could not find file '/TestFiles/TestData/XsltApi/xmlResolver_document_function_absolute_uri.xsl'.

and DirectoryNotFoundException for other TestFiles paths. About 3,140 of the suite's 48,626 test cases fail this way, both in the non-R2R CI lane and in a trimmed ReadyToRun run.

The data is declared as test content, for example <Content Include="Xslt\TestFiles\**\*" Link="TestFiles\%(RecursiveDir)%(Filename)%(Extension)" CopyToOutputDirectory="PreserveNewest" />. The tests open it with paths relative to the working directory, which is / in the guest. The test harness preopens the app bundle directory (--dir=.), and the WASI bundler deploys ContentWithTargetPath items under the bundle root through WasmFilesToIncludeInFileSystem, so /TestFiles/... should resolve.

The first step is to check whether the TestFiles tree is present in the generated AppBundle. If it isn't, the WASI nested publish is dropping these content items. If it is, the guest path resolution differs from what the tests assume.

Browser CoreCLR does not hit this because it excludes System.Private.Xml.Tests as a long-running suite.

Seen on #134813 (build 1617446).

Note

This issue was drafted with the help of GitHub Copilot.

[dotnet-policy-service]

Tagging subscribers to 'arch-wasm': @lewing, @pavelsavara
See info in area-owners.md if you want to be subscribed.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-xml
See info in area-owners.md if you want to be subscribed.