New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

allowedVersions filter not working at solution level #333

Closed
deepakaravindr opened this Issue Apr 1, 2015 · 13 comments

Comments

Projects
None yet
10 participants
@deepakaravindr
Member

deepakaravindr commented Apr 1, 2015

@mj1856

Add a single web project to a new solution in Visual Studio. Add jQuery 1.11.2 to the project.

Since jQuery 2.x is not supported in IE8, we want to stick with jQuery 1.11, so I use the allowedVersions attribute in the project's packages.config - like this:

<package id="jQuery" version="1.11.2" targetFramework="net451" allowedVersions="[1,2)" />

This works fine, and hides the 2.x packages from updates. But only from the command-line and the project-level GUI.

If you open the Nuget GUI from the solution level, it still shows jQuery 2.x updates - even though it would not be applicable for any project in the solution.

@mj1856

This comment has been minimized.

Show comment
Hide comment
@mj1856

mj1856 Apr 1, 2015

@deepakaravindr - Sorry I didn't realize I posted in the wrong place. Thanks for moving. 😃

With regard to the issue, also note that it's not just a display problem. If you go ahead and update from the solution level, it does update the package in the project, with a higher version than what is allowed by the allowedVersions attribute.

mj1856 commented Apr 1, 2015

@deepakaravindr - Sorry I didn't realize I posted in the wrong place. Thanks for moving. 😃

With regard to the issue, also note that it's not just a display problem. If you go ahead and update from the solution level, it does update the package in the project, with a higher version than what is allowed by the allowedVersions attribute.

@deepakaravindr deepakaravindr self-assigned this Apr 1, 2015

@yishaigalatzer yishaigalatzer added this to the 3.0.0-RTM milestone Apr 14, 2015

@yishaigalatzer

This comment has been minimized.

Show comment
Hide comment
@yishaigalatzer

yishaigalatzer Apr 14, 2015

@deepakaravindr we think this is fixed, please verify and close

yishaigalatzer commented Apr 14, 2015

@deepakaravindr we think this is fixed, please verify and close

@deepakaravindr

This comment has been minimized.

Show comment
Hide comment
@deepakaravindr

deepakaravindr Jun 5, 2015

Member

@yishaigalatzer, This is fixed in that, it is only a UI issue now. If you tried an upgrade, it will show an error stating something like 'constraints from packages.config prevent you from performing this action'. Note that this is true for powershell console too. If one performed 'Update-Package jQuery' in the case mentioned in the bug, it will throw the same error as in UI

Do we need to fix it to not even consider versions that are outside the allowedVersions? And, update it to highest possible version which is in the valid range

Member

deepakaravindr commented Jun 5, 2015

@yishaigalatzer, This is fixed in that, it is only a UI issue now. If you tried an upgrade, it will show an error stating something like 'constraints from packages.config prevent you from performing this action'. Note that this is true for powershell console too. If one performed 'Update-Package jQuery' in the case mentioned in the bug, it will throw the same error as in UI

Do we need to fix it to not even consider versions that are outside the allowedVersions? And, update it to highest possible version which is in the valid range

@yishaigalatzer

This comment has been minimized.

Show comment
Hide comment
@yishaigalatzer

yishaigalatzer Jun 5, 2015

I believe we should but it can be moved to update I

yishaigalatzer commented Jun 5, 2015

I believe we should but it can be moved to update I

@emgarten emgarten modified the milestones: 3.1.0-Beta, 3.0.0-RTM Jun 8, 2015

@VosmoyBit

This comment has been minimized.

Show comment
Hide comment
@VosmoyBit

VosmoyBit Jul 9, 2015

I've encountered a similar issue. The .nuspec for "MyPackage" restricts Common.Logging to version 2.1.2:

<dependencies>
  <dependency id="Common.Logging" version="[2.1.2]" />
</dependencies>

The package installs with no problems, but calling update-package from the PM console results in an error. The command attempts to install a higher version of Common.Logging and fails. Shouldn't update-package take into account the allowedVersions of installed packages and their dependencies?

Please see the .nuspec file, command output, and packages.config. Notice that the packages.config entry for Common.Logging has no allowedVersions attribute.

MyPackage.nuspec

<?xml version="1.0"?>
<package xmlns="http://schemas.microsoft.com/packaging/2011/10/nuspec.xsd">
  <metadata>
    <id>MyPackage</id>
    <version>3.12.1</version>
    <title>My Package</title>
    <authors>VosmoyBit</authors>
    <owners>VosmoyBit</owners>
    <requireLicenseAcceptance>false</requireLicenseAcceptance>
    <description>Description</description>
    <copyright>Copyright 2015</copyright>
    <dependencies>
      <dependency id="Common.Logging" version="[2.1.2]" />
    </dependencies>
  </metadata>
</package>

Command Log

PM> install-package MyPackage
Attempting to resolve dependency 'Common.Logging (= 2.1.2)'.
Installing 'Common.Logging 2.1.2'.
Successfully installed 'Common.Logging 2.1.2'.
Installing 'MyPackage 3.12.1'.
Successfully installed 'MyPackage 3.12.1'.
Adding 'Common.Logging 2.1.2' to MyProject.
Successfully added 'Common.Logging 2.1.2' to MyProject.
Adding 'MyPackage 3.12.1' to MyProject.
Successfully added 'MyPackage 3.12.1' to MyProject.

PM> update-package -whatIf
No updates available for 'MyPackage' in project 'MyProject'.
Updating 'Common.Logging' from version '2.1.2' to '3.2.0' in project 'MyProject'.
update-package : Updating 'Common.Logging 2.1.2' to 'Common.Logging 3.2.0' failed. Unable to find a version of 'MyPackage' that is compatible with 'Common.Logging 3.2.0'.
At line:1 char:1
+ update-package -whatIf
+ ~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Update-Package], Exception
    + FullyQualifiedErrorId : NuGetCmdletUnhandledException,NuGet.PowerShell.Commands.UpdatePackageCommand

packages.config

<?xml version="1.0" encoding="utf-8"?>
<packages>
  <package id="MyPackage" version="3.12.1" targetFramework="net45" />
  <package id="Common.Logging" version="2.1.2" targetFramework="net45" />
</packages>

VosmoyBit commented Jul 9, 2015

I've encountered a similar issue. The .nuspec for "MyPackage" restricts Common.Logging to version 2.1.2:

<dependencies>
  <dependency id="Common.Logging" version="[2.1.2]" />
</dependencies>

The package installs with no problems, but calling update-package from the PM console results in an error. The command attempts to install a higher version of Common.Logging and fails. Shouldn't update-package take into account the allowedVersions of installed packages and their dependencies?

Please see the .nuspec file, command output, and packages.config. Notice that the packages.config entry for Common.Logging has no allowedVersions attribute.

MyPackage.nuspec

<?xml version="1.0"?>
<package xmlns="http://schemas.microsoft.com/packaging/2011/10/nuspec.xsd">
  <metadata>
    <id>MyPackage</id>
    <version>3.12.1</version>
    <title>My Package</title>
    <authors>VosmoyBit</authors>
    <owners>VosmoyBit</owners>
    <requireLicenseAcceptance>false</requireLicenseAcceptance>
    <description>Description</description>
    <copyright>Copyright 2015</copyright>
    <dependencies>
      <dependency id="Common.Logging" version="[2.1.2]" />
    </dependencies>
  </metadata>
</package>

Command Log

PM> install-package MyPackage
Attempting to resolve dependency 'Common.Logging (= 2.1.2)'.
Installing 'Common.Logging 2.1.2'.
Successfully installed 'Common.Logging 2.1.2'.
Installing 'MyPackage 3.12.1'.
Successfully installed 'MyPackage 3.12.1'.
Adding 'Common.Logging 2.1.2' to MyProject.
Successfully added 'Common.Logging 2.1.2' to MyProject.
Adding 'MyPackage 3.12.1' to MyProject.
Successfully added 'MyPackage 3.12.1' to MyProject.

PM> update-package -whatIf
No updates available for 'MyPackage' in project 'MyProject'.
Updating 'Common.Logging' from version '2.1.2' to '3.2.0' in project 'MyProject'.
update-package : Updating 'Common.Logging 2.1.2' to 'Common.Logging 3.2.0' failed. Unable to find a version of 'MyPackage' that is compatible with 'Common.Logging 3.2.0'.
At line:1 char:1
+ update-package -whatIf
+ ~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Update-Package], Exception
    + FullyQualifiedErrorId : NuGetCmdletUnhandledException,NuGet.PowerShell.Commands.UpdatePackageCommand

packages.config

<?xml version="1.0" encoding="utf-8"?>
<packages>
  <package id="MyPackage" version="3.12.1" targetFramework="net45" />
  <package id="Common.Logging" version="2.1.2" targetFramework="net45" />
</packages>
@yishaigalatzer

This comment has been minimized.

Show comment
Hide comment
@yishaigalatzer

yishaigalatzer Jul 9, 2015

@VosmoyBit this seems related but not the same issue. Can you please open a separate issue and tell us some more about what version of visual studi and nuget you are using.

Also its a really bad form to lock a version like you are doing unless you know that no other version will work or you only intend your package to be used in incredibly limited and non public scenarios. The reason is that if another package wants 2.1.3 because of a bug fix it will require you to reship and the conflict just can't be resolved. The comment is obviously a generality and your scenario might fall in the very narrow definition of when things are applicable.

yishaigalatzer commented Jul 9, 2015

@VosmoyBit this seems related but not the same issue. Can you please open a separate issue and tell us some more about what version of visual studi and nuget you are using.

Also its a really bad form to lock a version like you are doing unless you know that no other version will work or you only intend your package to be used in incredibly limited and non public scenarios. The reason is that if another package wants 2.1.3 because of a bug fix it will require you to reship and the conflict just can't be resolved. The comment is obviously a generality and your scenario might fall in the very narrow definition of when things are applicable.

@VosmoyBit

This comment has been minimized.

Show comment
Hide comment
@VosmoyBit

VosmoyBit Jul 10, 2015

@yishaigalatzer, thank you for the response. I've created issue #916 and added the missing information.

I agree with your points about version locking. Unfortunately, the project I'm working on still uses an older version of the Common.Logging API and is incompatible with the newer packages.

VosmoyBit commented Jul 10, 2015

@yishaigalatzer, thank you for the response. I've created issue #916 and added the missing information.

I agree with your points about version locking. Unfortunately, the project I'm working on still uses an older version of the Common.Logging API and is incompatible with the newer packages.

@mj1856

This comment has been minimized.

Show comment
Hide comment
@mj1856

mj1856 Dec 29, 2015

FYI, with the current VS2015 + Nuget 3.3.0.167, I am seeing the jQuery update available both at the solution level and at the project level now as well.

The package config line is:

<package id="jQuery" version="1.11.3" targetFramework="net46" allowedVersions="[1,2)" />

It still suggests upgrading to jQuery 2.1.4, despite the allowedVersions attribute.

However, if I try to upgrade (at either level), then I get an error:

Unable to resolve 'jQuery'. An additional constraint '(≥ 1.0.0 && < 2.0.0)' defined in packages.config prevents this operation.

That's good that it prevents it, but also it creates an additional problem - If I try to update ALL packages, the error prevents other packages from being installed.

mj1856 commented Dec 29, 2015

FYI, with the current VS2015 + Nuget 3.3.0.167, I am seeing the jQuery update available both at the solution level and at the project level now as well.

The package config line is:

<package id="jQuery" version="1.11.3" targetFramework="net46" allowedVersions="[1,2)" />

It still suggests upgrading to jQuery 2.1.4, despite the allowedVersions attribute.

However, if I try to upgrade (at either level), then I get an error:

Unable to resolve 'jQuery'. An additional constraint '(≥ 1.0.0 && < 2.0.0)' defined in packages.config prevents this operation.

That's good that it prevents it, but also it creates an additional problem - If I try to update ALL packages, the error prevents other packages from being installed.

@yishaigalatzer

This comment has been minimized.

Show comment
Hide comment
@yishaigalatzer

yishaigalatzer Dec 29, 2015

@mj1856 yes, we plan to fix this in the next release.

yishaigalatzer commented Dec 29, 2015

@mj1856 yes, we plan to fix this in the next release.

@yishaigalatzer yishaigalatzer assigned alpaix and unassigned feiling Feb 22, 2016

@yishaigalatzer yishaigalatzer modified the milestones: 3.4 Beta, 3.4 RTM Feb 25, 2016

@alpaix alpaix modified the milestones: 3.5 Beta, 3.4 RTM Mar 1, 2016

@yishaigalatzer yishaigalatzer modified the milestones: 3.5 Beta, 3.5 RC Apr 8, 2016

@yishaigalatzer yishaigalatzer modified the milestones: 3.5 RC, 3.5 Beta Apr 8, 2016

@MrCsabaToth

This comment has been minimized.

Show comment
Hide comment
@MrCsabaToth

MrCsabaToth Jul 3, 2016

I'm trying to prevent the installation of the new jQuery 3.0.0.1. I have a project level packages.config, with

<package id="jQuery" version="2.2.4" allowedVersions="[2,3)" targetFramework="net461" />

The 3.0.0.1 jQuery is offered in the Manage NuGet Packages.../Updates project level GUI.

MrCsabaToth commented Jul 3, 2016

I'm trying to prevent the installation of the new jQuery 3.0.0.1. I have a project level packages.config, with

<package id="jQuery" version="2.2.4" allowedVersions="[2,3)" targetFramework="net461" />

The 3.0.0.1 jQuery is offered in the Manage NuGet Packages.../Updates project level GUI.

@MrCsabaToth

This comment has been minimized.

Show comment
Hide comment
@MrCsabaToth

MrCsabaToth Jul 3, 2016

jQuery 3.0 contains more breaking changes as opposed to 1.x -> 2.x upgrade. So I expect more people popping up with that problem in the near future.

MrCsabaToth commented Jul 3, 2016

jQuery 3.0 contains more breaking changes as opposed to 1.x -> 2.x upgrade. So I expect more people popping up with that problem in the near future.

@MrCsabaToth

This comment has been minimized.

Show comment
Hide comment
@MrCsabaToth

MrCsabaToth Jul 3, 2016

All right, as someone mentioned, this is now just a GUI issue. If I actually try to perform the upgrade, the constraint prevents it:

Unable to resolve 'jQuery'. An additional constraint '(>= 2.0.0 && < 3.0.0)' defined in packages.config prevents this operation.

MrCsabaToth commented Jul 3, 2016

All right, as someone mentioned, this is now just a GUI issue. If I actually try to perform the upgrade, the constraint prevents it:

Unable to resolve 'jQuery'. An additional constraint '(>= 2.0.0 && < 3.0.0)' defined in packages.config prevents this operation.
@daniefer

This comment has been minimized.

Show comment
Hide comment
@daniefer

daniefer Jul 29, 2016

This still fails for me when running from command line and using the -IncludePrerelease option. I am hosting an internal NuGet server which has a pre-release patch version of 2016.4.9-alpha available. My current package version is 2016.4.8 and I have a constraint set to [2016.4,2016.5). Shouldn't the pre-release be used when the -IncludePrerelease option is specified?

I haven't tried this in the GUI yet cause I need to script this update as part of our build process.

System Setup

  • Visual Studio Professional 2015 with Update 2
  • Full Command: Update-Package -Id "packageName" -IncludePrerelease -ToHighestPatch

PS - Sorry if I am doing this in the wrong place, this is the first time I have interacted with the community.

daniefer commented Jul 29, 2016

This still fails for me when running from command line and using the -IncludePrerelease option. I am hosting an internal NuGet server which has a pre-release patch version of 2016.4.9-alpha available. My current package version is 2016.4.8 and I have a constraint set to [2016.4,2016.5). Shouldn't the pre-release be used when the -IncludePrerelease option is specified?

I haven't tried this in the GUI yet cause I need to script this update as part of our build process.

System Setup

  • Visual Studio Professional 2015 with Update 2
  • Full Command: Update-Package -Id "packageName" -IncludePrerelease -ToHighestPatch

PS - Sorry if I am doing this in the wrong place, this is the first time I have interacted with the community.

alpaix added a commit to alpaix/NuGet.Client that referenced this issue Aug 2, 2016

Fixed allowedVersions update filter at solution level UI
Fixes NuGet/Home#333.

Re-wrote `UpdatePackageFeed.GetPackagesWithUpdatesAsync` so that it
retrieves updates per project with respect to individual allowedVersions
filter; then it unifies the list of package update candidates. This method
serves solution level updates search.

Changed the signature of
`MultiSourcePackageMetadataProvider.GetLatestPackageMetadataAsync` by
adding `project` argument to retrieve update for. The only consumer of this
method is a PMC commandlet calling it within a single project context (never
for solution or multiple-project context).

Added tests

alpaix added a commit to alpaix/NuGet.Client that referenced this issue Aug 2, 2016

Fixed allowedVersions update filter at solution level UI
Fixes NuGet/Home#333.

Re-wrote `UpdatePackageFeed.GetPackagesWithUpdatesAsync` so that it
retrieves updates per project with respect to individual allowedVersions
filter; then it unifies the list of package update candidates. This method
serves solution level updates search.

Changed the signature of
`MultiSourcePackageMetadataProvider.GetLatestPackageMetadataAsync` by
adding `project` argument to retrieve update for. The only consumer of this
method is a PMC commandlet calling it within a single project context (never
for solution or multiple-project context).

Added tests

alpaix added a commit to alpaix/NuGet.Client that referenced this issue Aug 2, 2016

Fixed allowedVersions update filter at solution level UI
Fixes NuGet/Home#333.

Re-wrote `UpdatePackageFeed.GetPackagesWithUpdatesAsync` so that it
retrieves updates per project with respect to individual allowedVersions
filter; then it unifies the list of package update candidates. This method
serves solution level updates search.

Changed the signature of
`MultiSourcePackageMetadataProvider.GetLatestPackageMetadataAsync` by
adding `project` argument to retrieve update for. The only consumer of this
method is a PMC commandlet calling it within a single project context (never
for solution or multiple-project context).

Added tests

@alpaix alpaix modified the milestones: 3.5 RTM, 3.6 Beta2 Aug 2, 2016

@rrelyea rrelyea added Area:VS.Client and removed Area:SDK labels Sep 1, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment