bazelbuild
Enable publish of library targets
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 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.
I have never used dotnet publish for an class library so I'm curious what you usecase is? But If it's supported by the dotnet CLI then I see no reason for not allowing it in rules_dotnet. I think we can share 90% of the code that i used for publish_binary, my guess is that the runtimeconfig and deps.json and apphost are not created when publishing an library?
I have never used
dotnet publishfor an class library so I'm curious what you usecase is?
It's actually in service of what I touched on in #359. dotnet, or more specifically "dotnet test", really does not play well with bazel's runfiles layout in my experience. I can avoid this by collecting all runtime references in a single folder which dotnet is more accustomed to handling, and in this case I'm building a library that "dotnet test" loads at runtime.
my guess is that the runtimeconfig and deps.json and apphost are not created when publishing an library?
I don't know of any official documentation that specifies the behavior, but based on my own testing a published library will include a deps.json but no apphost or runtimeconfig.