2

Scenario: I want to create and publish a library.

In the Java world: Using Gradle, I create a project using the java-library Gradle plugin. I can specify the dependencies using both the api configuration and the implementation configuration. This approach has these properties:

  • When compiling the library, the direct dependencies are resolved, but the transitive dependencies are only resolved if they are required for the compilation process. This makes the resolution process a lot faster, however, version conflicts might remain hidden until the library actually needs to run.
  • Consumers of my library can benefit from this behavior as well, since they only need the api dependencies of my library to compile their library/application.

In the .NET world: Using nuget, I personally didn't come across the same distinction. There seems to be A) only one kind of dependency (no distinction between API and implementation), and B) there is no similar concept to the compile and runtime classpaths as in Java. This also means that in order to compile the library, all dependencies - direct and transitive - are resolved, even if most of those are not required at all.

Question: Is there really no similar distinction in .NET? And if not, is there any good reason for it?

domin
  • 1,192
  • 1
  • 7
  • 28

1 Answers1

0

Since nobody answered in five days, I want to give it a try

I'd argue that NuGet/.NET support this as well, see here and here. I can specify which content of a foreign dependency I'm referencing can be consumed by other projects/packages.
Using IncludeAssets, ExcludeAssets and PrivateAssets are very fine-grained ways of controlling a dependency's assets.

mu88
  • 4,156
  • 1
  • 23
  • 47
  • 1
    Thanks! :) I've looked into these as well, but figured that this is a different use case. Here, we select parts of the *contents* of a referenced package X. This has no effect on the transitive dependencies referenced by X – they get resolved all the same. In the Java/Gradle world, this would be the [variant selection](https://docs.gradle.org/current/userguide/variant_model.html#understanding-variant-selection) that is much more flexible and even includes which transitive dependencies are associated to each variant. However, this feature is only in Gradle, not Maven. – domin Sep 21 '22 at 19:46