search

fsprojects / Paket

A dependency manager for .NET with support for NuGet packages and Git repositories.
https://fsprojects.github.io/Paket/
MIT License
2.02k stars 520 forks source link

is Paket supposed to respect the default dll path for nuget dependencies? #2206

Open dportzline83 opened 7 years ago

dportzline83 commented 7 years ago

Description

When installing a nuget dependency that has a dll in the root of the lib folder as well as a .NET 3.5 targeted version of the dll in a NET35 folder, Paket seems to always use the dll in the NET35 folder. It has the same behavior when no framework version is specified or when framework: >= net40 is specified in the paket.references file.

Repro steps

  1. Have a nuget with a default .dll in the lib folder and a dll in a NET35 subdirectory.
  2. Have the nuget dependency listed in the paket.dependencies file.
  3. Have the dependency listed in a paket.references file for a project.
  4. Run paket.exe install

Expected behavior

The project file should reference the default dll in the nuget.

Actual behavior

The project file references the dll in the NET35 folder.

cdrnet commented 7 years ago

Assuming your project targets .Net 4.0 or newer, the Paket behavior looks correct to me. Since .Net 3.5 libraries are compatible to .Net 4.0, the net35 folder wins over the fallback/root.

Maybe you can ask the package maintainer to put the .Net 4.0 (and higher) library into a "net40" folder instead? This is the common pattern for special casing .Net 3.5 and works well in my experience.

dportzline83 commented 7 years ago

The project targets 4.6. I did already try throwing it in a net40 folder and that works. It just seemed odd to me that the older framework version would take precedence over the root. But, perhaps you're right that it makes sense because of the compatibility between 3.5 and 4.0. As it turns out, this particular package is an internal one that I can change, so ultimately I can solve it that way.

cdrnet commented 7 years ago

Yes, I wish the NuGet team would document this better. The semantics of these folders is not "match exactly, or fall back", but "find all compatible ones, choose the best one according to rules, or fall back", with rules such that an exact target platform match always wins over compatible platforms (e.g. on .Net 4.6, net35 wins over PCL) and that the closer versions win (e.g. on .Net 4.6 net40 wins over net35). In my opinion these semantics and rules do make sense and are quite flexible in practice, but they are barely documented (as far as I know).