It appears that when i ask for a specific version of an assembly if there is a greater version in the local cache it picks its.
I have asked for 9.0.1 but its given me 10.0.2
Also I dont know why there is a NetStandard.Library reference in there as well ?
This is the projectNancyOwinConsoleApplication.zip (1.9 MB)
Cheers,
John
yes. that’s how it is supposed to work. specifying a version number, plain, means “that version or later”. you need to use brackets to limit versioning, e.g. ”9.0]”, to limit it from picking a higher version.
Thanks.
When I add a reference from the add reference dialog. Adding a specific version I get this
<NuGetReference Include="Newtonsoft.Json:6.0.6" />
Shouldnt that also stick brackets around the version ?
<NuGetReference Include="Newtonsoft.Json:[6.0.6]" />i guess that could be debated. you think the common scenario is that you’d want to tie it to a specific version? the syntax (“just a number means any version higher than”) seems to indicate that this is the most common case?
that said i’ll definitely need to expose some UI to change it…
I think the default should be to tie it to a specific version.
Later versions might have changed the interface or have bugs. You either get build errors or buggy/unexpected behaviour.
You might be developing with one version and deploying another from say a build server.
I think It would be great if there was UI to specify ranges allowed in the link.
I think this could male stuff fail more often what desired though. If you reference a strict specific version of a package, the build would fail as soon as a another dependency pulls in a newer version of the same package. I’ve seen tis countless times, tire’s a reference to, say 4.0 of something, but soon or later, a different dependency pulls in 4.3 of the same.
i will add some UI for configuring this, post RTM for 9.1. But i’ll stick with defaulting to “Minimum version, inclusive”, for now…
—marc
Im not sure that references you add should be “minimum version inclusive”
If I add a specific version of a library, then I would expect to always get it.
If I add 2 libraries dependant on another, I would expect to get the minimum version of the dependant assembly that satisfies the constraints of the 2 libraries.
If the version constraints between the 2 cant be satisfied, I would expect to be unable to add the second reference.
If I have already added a version of the dependant assembly to the project as a direct reference. When I add a library with that as a dependency, if the version doesn’t satisfy its constraints I would expect to be unable to add it.
When your resolving references it looks like your including pre release packages.
I was looking at the references in elmah
Is that intentional ?
according to the resolving rules, yeah.
Shouldnt that be something I have to agree to before they are included ?
i guess an argument could be made, if we can come top with exact rules.
right now, i pick the highest version i can find that’s a match for the configured range (i.e. the highest, period, if nipper bound is defined via ] or )). According to semantic versioning rules version+suffix counts as lower than just the (same) version but higher than previous versions. so ``2.0.0-alphais, technically, a valid version, higher than1.2, and if no2.0.0` w.o suffix is present, it will be considered the highest version.
There is this
It just says package manager by default doesnt include pre release versions.
There is also this note
A stable package release cannot have a pre-release dependency. This avoids accidentally installing a potentially unstable releases.
thanx. i’ll review and see how to incorporate that logic.
