Build fails when depending on `Microsoft.TestPlatform.TestHost`

[redsun82]

After upgrading from 0.17.4 to 0.19.2 in our paket-based C# codebase we found we could no longer build our unit tests, with the error being:

error CS0009: Metadata file '/home/redsun82/.cache/bazel/_bazel_redsun82/9c7f9952de3c23b0f1cc287e3faecff0/sandbox/processwrapper-sandbox/21/execroot/_main/external/+main_extension+nuget.microsoft.testplatform.testhost.v17.12.0/lib/netcoreapp3.1/x86/msdia140.dll' could not be opened -- PE image doesn't contain managed metadata.
error CS0009: Metadata file '/home/redsun82/.cache/bazel/_bazel_redsun82/9c7f9952de3c23b0f1cc287e3faecff0/sandbox/processwrapper-sandbox/21/execroot/_main/external/+main_extension+nuget.microsoft.testplatform.testhost.v17.12.0/lib/netcoreapp3.1/x64/msdia140.dll' could not be opened -- PE image doesn't contain managed metadata.

After a bit of a sleuthing session I could trace it back to a specific code change in rules_dotnet.

I managed to create a reproducer in the paket example in this repo with F# in https://github.com/redsun82/rules_dotnet/tree/bug, (diff) with the error there being

error FS0229: Error opening binary file '/home/redsun82/.cache/bazel/_bazel_redsun82/78d8a1b3e78098d8f05ed9b2952c7522/sandbox/processwrapper-sandbox/9/execroot/_main/external/+main_extension+nuget.microsoft.testplatform.testhost.v17.14.1/lib/net8.0/x64/msdia140.dll': /home/redsun82/.cache/bazel/_bazel_redsun82/78d8a1b3e78098d8f05ed9b2952c7522/sandbox/processwrapper-sandbox/9/execroot/_main/external/+main_extension+nuget.microsoft.testplatform.testhost.v17.14.1/lib/net8.0/x64/msdia140.dll: bad cli header, rva 0

and some other along the same line.

Now reverting this specific line change makes the build work again, as can be seen in https://github.com/redsun82/rules_dotnet/tree/fix (diff).

It turns out that that change caused the following entries to be added to the generated tfm_filegroups in that nuget archive repository:

lib/netcoreapp3.1/x64/msdia140.dll
lib/netcoreapp3.1/x86/msdia140.dll

I have no idea if it's rules_dotnet at fault here for adding those files, or if the nuget package in question is somehow malformed. I don't know the dotnet ecosystem well enough to tell.

For the moment we will be able to work around this by patching rules_dotnet with that micro-revert.

cc @purkhusid as the author of the above linked PR.