Losing version-range when 'dotnet pack'
See original GitHub issueDescription
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
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:
- Created 6 years ago
- Reactions:6
- Comments:16 (16 by maintainers)
Top GitHub Comments
@baronfel I will start working on it now (I need to extract the “essence of the problem” from quite large commercial codebase).
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)