question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Losing version-range when 'dotnet pack'

See original GitHub issue

Description

Yet again, it might not be paket’s problem, but maybe there is something you can do about it.

Guys from ‘NLog’ team made a mess and rolled back version making making 4.5 newer than 5.0.

My library, let’s call it libA requires version 4.5 so paket.dependencies contains:

nuget NLog ~> 4 beta

and it is getting 4.5. So far, so good.

Now, my other project, let’s call it appB, which uses libA does not know or care about NLog. The only dependency it has is libA:

nuget libA

But… when I do paket install it resolves NLog version 5.0.

Apparently, dotnet pack for libA puts the restriction >= 4.5 instead of >= 4.5 && < 5.

Long story short, my very precise restrictions about versions are lost when crossing dotnet pack boundary.

Repro steps

nlfu.zip

Run setup.cmd. Notice NLog 4 is referenced in libA (correctly) but appB references NLog 5 (wrongly).

Expected behavior

Both libA and appB reference version 4 of NLog.

Actual behavior

Restrictions are “forgotten”, and appB references “newest” version of “NLog”

Known workarounds

Explicitly put restrictions in appB again (even if assembly is not used directly).

Issue Analytics

  • State:open
  • Created 6 years ago
  • Reactions:6
  • Comments:16 (16 by maintainers)

github_iconTop GitHub Comments

1reaction
MiloszKrajewskicommented, Apr 28, 2020

@baronfel I will start working on it now (I need to extract the “essence of the problem” from quite large commercial codebase).

0reactions
MiloszKrajewskicommented, Apr 29, 2020

I think the problem was a little bit different: I am stupid. I didn’t pay attention to Could not find version range for package Microsoft.Extensions.DependencyInjection because… it wasn’t in red (or yellow). Definitely saying why (“because it is not in paket.dependencies”) would help, but really… color was primary reason.

I behaved like an idiot and I feel really ashamed about that.

(I would still expect this to be warning during build - not only pack, but that’s minor)

Read more comments on GitHub >

github_iconTop Results From Across the Web

Package version is always 1.0.0 with dotnet pack
1.0.0.nupkg . What am I missing? Here is my pack command: dotnet pack $projectFile -o $currentDirectory.
Read more >
NuGet Package Restore
Open a command line and switch to the directory that contains your project file. Run dotnet restore . Important. To add a missing...
Read more >
MSBuild reference for .NET SDK projects
The PackRelease property is similar to the PublishRelease property, except that it changes the default behavior of dotnet pack .
Read more >
NuGet Package Version Reference
Always specify a version or version range for package dependencies in project files, packages.config files, and .nuspec files.
Read more >
Nuget package installer does not install dependencies (.net ...
I have a test project, wherin I'm using PeanutButter.TempDb.MySql (I'm also the owner/maintainer of the PeanutButter.* packages). This package depends on:.
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found