Transitive dependencies of nuget packages don't contribute to build

[criemen]

Hi,

I'm running into a problem with using the xunit package from nuget with the paket/bazel integration.
The xunit package is itself empty, as far as I'm aware, and transitively depends on xunit.core, which in turn depends on xunit.extensibility.core which has the actual DLL which dotnet needs to compile against.

I have setup a simple project at https://github.com/criemen/rules-dotnet-repro, which compiles with dotnet build, but fails to compile with bazelisk build //:Program, as bazel can't find the Xunit namespace.
Looking into Program.dll-0.params, this seems to be the case as the transitive dependency xunit.extensibility.core doesn't contribute its DLL to the build invocation.

Adding @paket.main//xunit.extensibility.core to the deps of the project fixes the build, as expected.
As this is an implementation detail of the xunit package, as user I don't want to think about that and specify that dependency by hand.

[purkhusid]

The repo appears to be private.
But this is the default behavior of rules_dotnet which similar to the <DisableTransitiveProjectReferences>true</DisableTransitiveProjectReferences> in MSBuild.

You can override this by using --@rules_dotnet//dotnet/settings:strict_deps=false and then all transitive dependencies will be pulled into every compilation action. Note that using this flag will make your targets more prone to be invalidated and the analysis can also be slower in large repos.

[purkhusid]

We also have the export attribute which allows you to declare additional libraries that will be propagated. We don't support adding this to the generated nuget targets but I think it might make sense to have an additional configuration file that could be passed to paket2bazel which adds additional attributes to the nuget targets.

[criemen]

I made the repo public - apologies.

I am using the transitive/strict dependency checking for Java and C++, and it's very useful there, so I'd rather not disable it for C# (but it does fix the build problem here). It is a viable workaround for now though that is unblocking me.

For 3rdparty dependencies to be useful, groups should indeed have export set, instead of using a regular deps attribute. I can't imagine that xunit is alone in grouping several useful dependencies together as one nuget package.