EBuild: Referenced version is incorrect

(JohnMoshakis) #1

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)


(marc hoffman) #2

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.

(marc hoffman) #3

(JohnMoshakis) #4


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]" />

(marc hoffman) #5

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…

(JohnMoshakis) #6

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.

(marc hoffman) #7

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…


(JohnMoshakis) #8

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.

(JohnMoshakis) #9

When your resolving references it looks like your including pre release packages.

I was looking at the references in elmah

Is that intentional ?

(marc hoffman) #10

according to the resolving rules, yeah.

(JohnMoshakis) #11

Shouldnt that be something I have to agree to before they are included ?

(marc hoffman) #12

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.

(JohnMoshakis) #13

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.

(marc hoffman) #14

thanx. i’ll review and see how to incorporate that logic.