Enable publish of library targets

[Inirit]

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.

[purkhusid]

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?

[Inirit]

I have never used dotnet publish for 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.

[peakschris]

I'm facing similar issues in #450. @Inirit could you share the mechanism you are using to collect the runtime references into a single folder before testing?

[Inirit]

I'm facing similar issues in #450. @Inirit could you share the mechanism you are using to collect the runtime references into a single folder before testing?

Quoting from my original post:

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)

Unfortunately I cannot provide any more detail than that as I no longer have access to the Bazel project I was working on at that time.