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

"Upgrade vailable" filter shows upgrades that violate the version constraint #1094

Closed
MartinJohns opened this Issue Aug 2, 2015 · 15 comments

Comments

Projects
None yet
@MartinJohns

MartinJohns commented Aug 2, 2015

Hello. I'm using Visual Studio 2015 Prof RTM. When I select "Manage NuGet Packages" on my project and select the "Upgrade available" filter I see updates to my packages that violate the version constraint.

Specifically I have this entry in my packages.config:

NuGet shows me an upgrade is available to version 5.2.3.

The expected behavior would be to only show upgrades to versions within my specified constraint.

@emgarten

This comment has been minimized.

Show comment
Hide comment
@emgarten

emgarten Aug 4, 2015

Contributor

@MartinJohns what is the entry in packages.config? Are you using allowedVersions?

Contributor

emgarten commented Aug 4, 2015

@MartinJohns what is the entry in packages.config? Are you using allowedVersions?

@MartinJohns

This comment has been minimized.

Show comment
Hide comment
@MartinJohns

MartinJohns Aug 5, 2015

@emgarten
The entry in my packages.config is this:

<package id="Microsoft.AspNet.Mvc" version="4.0.40804.0" targetFramework="net4" allowedVersions="(, 5.0.0)" />

This clearly says I want all updates until version 5. The NuGet manager in Visual Studio shows that there is an update to version 5 available. This violates the specified allowedVersions constraint. Trying to update obviously fails, as this project is only .NET 4.0 and MVC5 does not support .NET 4.0 anymore.

The PoweShell command "Update-Package" recognizes this constraint correctly. It updates to all packages less than version 5.

Here's an image of the issue:

Imgur

I just noticed another bug, but I gotta see if there's already an issue. If NuGet found an update and installed it, it will replace my entry in the packages.config with the new version. While doing this it removes the allowedVersions constraint. The expected behavior would be to take this over.

MartinJohns commented Aug 5, 2015

@emgarten
The entry in my packages.config is this:

<package id="Microsoft.AspNet.Mvc" version="4.0.40804.0" targetFramework="net4" allowedVersions="(, 5.0.0)" />

This clearly says I want all updates until version 5. The NuGet manager in Visual Studio shows that there is an update to version 5 available. This violates the specified allowedVersions constraint. Trying to update obviously fails, as this project is only .NET 4.0 and MVC5 does not support .NET 4.0 anymore.

The PoweShell command "Update-Package" recognizes this constraint correctly. It updates to all packages less than version 5.

Here's an image of the issue:

Imgur

I just noticed another bug, but I gotta see if there's already an issue. If NuGet found an update and installed it, it will replace my entry in the packages.config with the new version. While doing this it removes the allowedVersions constraint. The expected behavior would be to take this over.

@yishaigalatzer

This comment has been minimized.

Show comment
Hide comment
@yishaigalatzer

yishaigalatzer Aug 6, 2015

Thanks for reporting it, this is a regression from Visual Studio 2013.

yishaigalatzer commented Aug 6, 2015

Thanks for reporting it, this is a regression from Visual Studio 2013.

@yishaigalatzer yishaigalatzer added this to the 3.2.0-Beta milestone Aug 6, 2015

@yishaigalatzer yishaigalatzer changed the title from [NuGet.VisualStudioExtension] "Upgrade vailable" filter shows upgrades that violate the version constraint to "Upgrade vailable" filter shows upgrades that violate the version constraint Aug 6, 2015

@RanjiniM RanjiniM self-assigned this Oct 6, 2015

@RanjiniM RanjiniM assigned feiling and unassigned RanjiniM Oct 7, 2015

@RanjiniM

This comment has been minimized.

Show comment
Hide comment
@RanjiniM

RanjiniM Oct 7, 2015

After discussing with Fei, I am assigning this bug to him. Currently while in the dialog we don't read packages.config and apply the constraints in the values show in the dropdown. We always return all listed versions available.Only when we invoke an action version constraints are applied. As Fei is working on redesigning the dialog he is going to add code to read packages.config while populating the dropdown.

RanjiniM commented Oct 7, 2015

After discussing with Fei, I am assigning this bug to him. Currently while in the dialog we don't read packages.config and apply the constraints in the values show in the dropdown. We always return all listed versions available.Only when we invoke an action version constraints are applied. As Fei is working on redesigning the dialog he is going to add code to read packages.config while populating the dropdown.

@regisbsb

This comment has been minimized.

Show comment
Hide comment
@regisbsb

regisbsb Oct 12, 2015

Cool will we need a visual studio update? @RanjiniM

regisbsb commented Oct 12, 2015

Cool will we need a visual studio update? @RanjiniM

@yishaigalatzer

This comment has been minimized.

Show comment
Hide comment
@yishaigalatzer

yishaigalatzer Oct 12, 2015

No visual studio update will be necessary, just a nuget extension update

yishaigalatzer commented Oct 12, 2015

No visual studio update will be necessary, just a nuget extension update

@yishaigalatzer

This comment has been minimized.

Show comment
Hide comment
@yishaigalatzer

yishaigalatzer Oct 26, 2015

This is a duplicate of #333 or at least very closely related. We should fix both in one go

yishaigalatzer commented Oct 26, 2015

This is a duplicate of #333 or at least very closely related. We should fix both in one go

@yishaigalatzer

This comment has been minimized.

Show comment
Hide comment
@yishaigalatzer

yishaigalatzer Mar 12, 2016

Also note this comment from a duplicate issue by @Advarius:

Visual Studio 2015 is used. I update package with allowedVersions="[1.0,1.1)" attribute from NuGet Package Manager. Current version of package is 1.0.72, available versions are 1.0.73 and 1.1.1.

Firstly, I can see that version "1.1.1" is available for update, which is not satisfy condition. But moreover, if I use Dependency behavior: "Ignore dependencies", nuget will update package to this version despite of constraint without any message.

yishaigalatzer commented Mar 12, 2016

Also note this comment from a duplicate issue by @Advarius:

Visual Studio 2015 is used. I update package with allowedVersions="[1.0,1.1)" attribute from NuGet Package Manager. Current version of package is 1.0.72, available versions are 1.0.73 and 1.1.1.

Firstly, I can see that version "1.1.1" is available for update, which is not satisfy condition. But moreover, if I use Dependency behavior: "Ignore dependencies", nuget will update package to this version despite of constraint without any message.

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

@alpaix alpaix modified the milestones: 3.5 RTM, 3.6 Beta Jul 26, 2016

@alpaix

This comment has been minimized.

Show comment
Hide comment

alpaix commented Jul 26, 2016

@alpaix alpaix closed this Jul 26, 2016

@JohnGalt1717

This comment has been minimized.

Show comment
Hide comment
@JohnGalt1717

JohnGalt1717 Nov 27, 2016

This still isn't fixed. Fully patched VS.net 2015 Update 3 with latest Nuget and the following line:

Still gets version 3 even though that clearly states get everything up to 3.0.0 and stop.

JohnGalt1717 commented Nov 27, 2016

This still isn't fixed. Fully patched VS.net 2015 Update 3 with latest Nuget and the following line:

Still gets version 3 even though that clearly states get everything up to 3.0.0 and stop.

@yishaigalatzer

This comment has been minimized.

Show comment
Hide comment
@yishaigalatzer

yishaigalatzer Nov 27, 2016

yishaigalatzer commented Nov 27, 2016

@NathanGloyn

This comment has been minimized.

Show comment
Hide comment
@NathanGloyn

NathanGloyn Dec 2, 2016

I have this problem as well. AFAIK I have latest Nuget installed (3.5.0.1484), but with the following packages entry I see upgrades offered both at a project and solution level:
<package id="IdentityModel" version="1.13.1" targetFramework="net452" allowedVersions="(,2.0)" />

NathanGloyn commented Dec 2, 2016

I have this problem as well. AFAIK I have latest Nuget installed (3.5.0.1484), but with the following packages entry I see upgrades offered both at a project and solution level:
<package id="IdentityModel" version="1.13.1" targetFramework="net452" allowedVersions="(,2.0)" />

@jainaashish

This comment has been minimized.

Show comment
Hide comment
@jainaashish

jainaashish Dec 5, 2016

Contributor

Can you try with latest NuGet from https://dist.nuget.org/index.html which is 3.5.0.1996 I see it working. If you still see issue, then pls share your sample solution.

Contributor

jainaashish commented Dec 5, 2016

Can you try with latest NuGet from https://dist.nuget.org/index.html which is 3.5.0.1996 I see it working. If you still see issue, then pls share your sample solution.

@azachert

This comment has been minimized.

Show comment
Hide comment
@azachert

azachert Dec 30, 2016

Just tested - it is working fine with latest version (3.5.0.1996)

azachert commented Dec 30, 2016

Just tested - it is working fine with latest version (3.5.0.1996)

@NathanGloyn

This comment has been minimized.

Show comment
Hide comment
@NathanGloyn

NathanGloyn Jan 25, 2017

This is working if you manage the packages at the individual project level, but if you do it at the solution level it still shows offers upgrades even if all the projects using the package have a restriction on the version.

NathanGloyn commented Jan 25, 2017

This is working if you manage the packages at the individual project level, but if you do it at the solution level it still shows offers upgrades even if all the projects using the package have a restriction on the version.

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