Should unlisted packages being included in "lowest version" resolution

[SimonCropp]

So when i install PropertyChanged.Fody 1.50.1 which has a non version dependency on Fody

Note i need -source "https://www.nuget.org/api/v2" since the indexing is currently broken in nuget v3 #1161

Via the Console

Install-Package PropertyChanged.Fody -Version 1.50.1  -source "https://www.nuget.org/api/v2"

<package id="Fody" version="1.13.0.0" targetFramework="net4" />
<package id="PropertyChanged.Fody" version="1.50.1" targetFramework="net4" developmentDependency="true" />

ie the lowest including unlisted

Via the UI

  <package id="Fody" version="1.28.3" targetFramework="net4" developmentDependency="true" />
  <package id="PropertyChanged.Fody" version="1.50.1" targetFramework="net4" developmentDependency="true" />

ie the lowest including listed

So which should it be?

And where is the rules about unlisted packages documented this documented?

[emgarten]

The UI results are correct here, listed versions are favored over unlisted versions. The idea of listed is specific to the source so if the package exists in a local source or another feed it will be marked as listed.

[SimonCropp]

The UI results are correct here, listed versions are favored over unlisted versions

wouldnt this result in an inconsistent build for people who have not opted into floating dependencies in project.json? ie they have not checked in project.json.lock (as recommended by nuget). so when restore happens for dependencies "what actually gets restored" will be dependent on "what is listed on a given day"?

[emgarten]

project.json does not use the listed setting when resolving dependencies. For project.json restores the packages are kept in the global packages folder which does not track listed/unlisted.

[SimonCropp]

packages are kept in the global packages folder which does not track listed/unlisted.

what about when restored on a clean machine?

[emgarten]

packages are kept in the global packages folder which does not track listed/unlisted.

what about when restored on a clean machine?

The results will be the same. Listed/Unlisted isn't used for project.json.

[SimonCropp]

Ok i must be missing something

You say

listed versions are favored over unlisted versions

and project.json does not include the "version of a dependency used" since that is in the lock file.

So on a package restore will project.json "use listed+unlisted packages when resolving dependencies with no specific version" OR "only use listed packages when resolving dependencies with no specific version"

[emgarten]

Package.config: Listed is favored
Project.json: Listed/Unlisted is not used

Your original example is using packages.config where listed is taken into consideration during installs and updates. For project.json where resolution happens at build time things are more likely to change as you pointed out and the listed/unlisted flag is not used.

[SimonCropp]

For project.json where resolution happens at build time things are more likely to change as you pointed out and the listed/unlisted flag is not used.

Ok so isnt this a bug since people will effectively be automatically getting floating dependencies while here #1192 (comment) you said

Users have to opt into the floating behavior.

[SimonCropp]

also

Package.config: Listed is favored
Project.json: Listed/Unlisted is not used

considering Package.config and Project.json can be mixed in the same solution wont this cause some very strange dependency resolutions?

[yishaigalatzer]

For project.json - unlisted cannot be accounted for, it will cause build instabilities
For packages.config - The version is determined at install, not at restore, and will let you pull in the latest etc.

Yes it might create inconsistencies, but that is not new, same as different packages.configs with a few different packages pulling different versions.

We are tracking support for unifying versions in the solution, but design haven't been done yet.