bazel-contrib / bazel-contrib/rules_dotnet
Enable publish of library targets
- Dominant language
- Starlark
- Stars
- 209
- Forks
- 98
- Avg merge
- 3h 59m
- Merged PRs (30d)
- 14
Description
If I understand correctly, rules_dotnet currently only supports the "publishing" of a *_binary target (assumed by the name of the "publish_binary" rule, but also by noticing _publish_binary_wrapper_impl in publish_binary.bzl assumes the existence of a DotnetBinaryInfo provider). This support was motivated by #280 where it was asked if there is an equivalent to the "dotnet publish" command, however the publishing of a binary target is only half of what "dotnet publish" can do, it ought to be able to publish *_library targets as well.
Before writing this issue I wanted to make sure I understood what "publish" is intended to mean in this context and that I wasn't asking for something that was never meant to be supported. While I couldn't find a 100% obvious answer that "dotnet publish" is meant to support both library and executable projects, I did find [this page](https://learn.microsoft.com/en-us/dotnet/core/project-sdk/msbuild-props#copylocallockfileassemblies) documenting how to configure a .csproj file to include referenced assemblies in the build output folder and underneath is a "tip" suggesting "dotnet publish" as an alternative way to achieve the same thing for a "class library".
This is the exact scenario I would like to leverage "publishing" for, to collect referenced runtime dlls in a single build output folder for a library. Currently this can be worked around by adding a dummy source file with a blank Main method and then building my code as a binary rather than a library (which is therefore able to be published by publish_binary), but ideally such a workaround would not be necessary.
Contributor guide
Research direction
Start by tracing the publish_binary rule and _publish_binary_wrapper_impl in publish_binary.bzl, especially its requirement for DotnetBinaryInfo. Compare how library targets are represented with binary targets and identify the existing publishing flow that would need to accept libraries. Done means a library target can collect its referenced runtime DLLs in one publish output without a dummy Main method.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- csharp
- Domain
- build-system
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 38/100