bazel-contrib / bazel-contrib/rules_dotnet
Build fails when depending on `Microsoft.TestPlatform.TestHost`
- Dominant language
- Starlark
- Stars
- 209
- Forks
- 98
- Avg merge
- 3h 59m
- Merged PRs (30d)
- 14
Description
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](https://github.com/bazel-contrib/rules_dotnet/compare/master..redsun82:rules_dotnet:bug)) 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](https://github.com/bazel-contrib/rules_dotnet/pull/492/files#diff-3e2a8c91410af8c8bbce2f000028fc332c077f57290c9e2b72115b5944754e05L117) makes the build work again, as can be seen in https://github.com/redsun82/rules_dotnet/tree/fix ([diff](https://github.com/bazel-contrib/rules_dotnet/compare/master..redsun82:rules_dotnet:fix#diff-3e2a8c91410af8c8bbce2f000028fc332c077f57290c9e2b72115b5944754e05)).
It turns out that that change caused the following entries to be added to the generated `tfm_filegroup`s 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.
Contributor guide
Research direction
Start with the paket F# reproducer and compare the bug and fix diffs, especially the line changed in PR #492. Inspect the generated tfm_filegroups in the NuGet archive repository and determine why the x86 and x64 msdia140.dll files are included. Done means the affected unit-test builds succeed without those native DLLs being treated as managed metadata.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- csharp, fsharp
- Domain
- build-system, tooling
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100