Version Range support in UI and PMC update

[zhili1208]

Hi everyone at NuGet.org.

I’m using new format of the nuget package management that is fully integrated with MSBuild, it is very awesome and work very good except that it have one really odd error.
In old format(packages.config), we could use allowedVersions to limit version of allowed nugets, in this new format Version range should specified in Version tag of the PackageReference but
we have 2 problems with this:

1. PackagaeManagerConsole does not respect this version limit,
   So if I have Version=”[1.0.0, 1.5.0)” and there is a version 2.0.0 of the package, UI respect my limitation and show no update but Update-Package command will update my
   reference to version 2.0.0
2. If package updated to a newer version(a version that is allowed in my range), then new version will be written in place of old version and it will remove my version range limit
   So if I have Version=”[1.0.0, 1.5.0)” and there is version 1.1.0 and 2.0.0 of the package, and I use nuget UI, it will update my project to version 1.1.0 as expected, but as a
   side effect it will change my Version tag to Version=”1.1.0” and so remove my version limitation, and now it will show that I have an update for version 2.0.0.

I want to know how I use this new format and use old good allowedVersions or something that have same effect.

[MattLavalleeMA]

Same here. Almost 2 years old for a P1??

[MagicAndre1981]

Any update on this issue? @nkolev92 @anangaur

We need to restrict the offered nuget updates similar to allowedVersions in packages.config.

[Indigo744]

This issue is still open, even though it is really a showstopper when multiple people may update packages using the UI. Every time we need to step in and add back the constraints...

This is madness. PackageReference is supposed to be "the new norm" but clearly lacks of basic usability like this, which is known for almost 3 years... Come on!

[MagicAndre1981]

@donnie-msft when will this be fixed? In 16.9? Why don't we get any response from you @nkolev92 @anangaur?

I opened my solution and now get tons of .net 5 updates when I want to do updates from .net core 3.1.9 to 3.1.10

I now used my filemanager to search for 3.1.9 to list all csprojs and next used Search&Replace from notepad3 to update from 3.1.9. to 3.1.10 🤮

[Bellarmine-Head]

So this ticket is apparently touted as the answer to these problems:-

1. .NET 7 packages are recommended for a .NET 6 project. (They will fail to install if there is an attempt to do so.)

2. The invalid .NET 7 packages are obscuring valid .NET 6 package updates, which the project/solution might well need for security.

As I have mentioned in other tickets that have been closed (e.g. because they are dups of this ticket, directly or indirectly): imagine Windows Update behaving in this way! Imagine you're on Windows 10 and Windows Update starts offering you Windows 11 updates which fail to install, and which hide genuine Windows 10 updates. The scenario is ridiculous of course, yet that is effectively what is happening wrt NuGet packages for .NET projects/solutions.

My understanding is that the problems described above will go away if this ticket is dealt with.

[StingyJack]

This is needed so that we can easily prevent versions of the Moq package that are 4.20 and later from being "whoops" upgraded in a project.

[ThomasHeijtink]

Now after almost 6 years, and still no improvements. Why is such a fundamental feature being ignored or procrastinated? You only need the package manager to honour the lowest framework version in a solution. This already covers 90% (if not more) of all use cases. You can always improve this later with other settings etc. But the majority of the people have a problem with having to deal a year long (if not longer) with their package update experience hampered and frustrated because the package manager is lacking such fundamental and basic feature.

[MagicAndre1981]

the Microsoft managers simply don't do coding and have no idea what is important and what not.

[Bellarmine-Head]

At a glacial pace, something might be happening: #5725 (comment)

[mr-davidc]

Just stumbled across this issue and am kinda shocked that functionality that exists in a packages.config file isn't available in the "new" PackageReference format...

[StingyJack]

Just stumbled across this issue and am kinda shocked that functionality that exists in a packages.config file isn't available in the "new" PackageReference format...

@mr-davidc - They broke a bunch of stuff with the move to package reference. install.ps1 scripts no longer work, no more xdt support, and one other thing that I dont recall (because I didn't use it). Not to mention all of the crippling bugs that came with Package referece.

[MagicAndre1981]

any update on this issue?

[ShockwaverReal]

Are we really stuck on this? I mean, it seems quite fundamental to me...
Plus, the UI for me it's showing the very latest version available regardless of what I specify in version attribute.

[Bellarmine-Head]

@ShockwaverReal - yes it seems we're really stuck on this. Another year, another .NET release, same old problem.

Here NuGet is offering to install an incompatible version of the packages, and hiding compatible versions that I might well need to upgrade to for security. Just like last year, and the year before, and the year before, and etc. Maybe they can ask "AI" to sort it out...

[ShockwaverReal]

@Bellarmine-Head - It's grotesque... in order to update hundreds of references to the latest compatible versions in my projects I have to manually update them ONE BY ONE through UI or csproj... Insane.

[mexmer]

@Bellarmine-Head - It's grotesque... in order to update hundreds of references to the latest compatible versions in my projects I have to manually update them ONE BY ONE through UI or csproj... Insane.

it's stupid and it was giving me headache, so what i'm doing is opening csproj, and with search and replace i replace all versions, then load project, and since i have automatic package restore enabled in visual studio, it does indeed download all missing packages.

yes, it's clunky workaround, but works ... it's maintable if you are doing it for handfull of project files, can't image doing it for large number of projects tho' ... maybe writing some automation tool.

[MagicAndre1981]

it's stupid and it was giving me headache, so what i'm doing is opening csproj, and with search and replace i replace all versions, then load project, and since i have automatic package restore enabled in visual studio, it does indeed download all missing packages.

this is what I also do for 4 years now

[MikeFarrington]

It's not perfect, but this command is helpful in identifying which packages have minor updates.

dotnet list package --outdated --highest-minor --highest-patch

[PeterKnaggs]

Six years now.

This is still and issue in 17.12.3

[StingyJack]

No programmer should be updating files ONE by ONE. Use a tool like notepad++ to do find and replace in files. If that doesn't work for you, then make a tool or script.

Powershell is great for dealing with XML and proj files.

[dominikjeske]

I just created powershell script for update nugets with ommiting non LTS versions. I think that with LTS release schedule this is standard behavior for many people out there. This feature is a MUST for me.

[vernou]

@dominikjeske, nice. Can you share the script?

[dominikjeske]

Just for a note - my script only lists dependencies because I want control what I'm updating but It is good starting point if you want also update

Write-Host "Reading dependencies for all versions..." -ForegroundColor Gray
$majorDepRaw = dotnet list package --outdated -f "net8.0" --format json

Write-Host "Reading dependencies for minior versions..." -ForegroundColor Gray
$miniorDepRaw = dotnet list package --outdated -f "net8.0" --highest-minor --format json

$majorDep = $majorDepRaw | ConvertFrom-Json
$miniorDep = $miniorDepRaw  | ConvertFrom-Json

$miniorBlackList = @("Microsoft.Extensions", "Microsoft.AspNetCore")
function ParseDependencies()
{
    [CmdletBinding()]
    param (
        $dependencies
    )
    $packages = @{}

    $dependencies.projects | ForEach-Object {
        $project = $_
        $project.frameworks | Where-Object { $_ -ne $null } | ForEach-Object {
            $framework = $_
            $framework.topLevelPackages | ForEach-Object {
                $package = $_
                if(!$packages.ContainsKey($package.id)) {
                    $packages[$package.id] = [PSCustomObject]@{
                        Id = $package.id
                        CurrentVersion = $package.resolvedVersion
                        NewVersion = $package.latestVersion
                    }
                }
            }
        }
    } 
    $packages
}

$packages = ParseDependencies $majorDep

Write-Host "---------------------All---------------------" -ForegroundColor Green
$packages.Values | Sort-Object -Property Id | ForEach-Object {
    $package = $_
    $skip = $false
    $miniorBlackList | ForEach-Object {
        $miniorBlack = $_
        if($package.Id.StartsWith($miniorBlack)) {
            $skip = $true
        }
    }
    if(!$skip) {
        Write-Host "$($package.Id) $($package.CurrentVersion)->$($package.NewVersion)"
    }
}

Write-Host "---------------------Minior---------------------" -ForegroundColor Green
$packagesMinior = ParseDependencies $miniorDep

$packagesMinior.Values | Sort-Object -Property Id | ForEach-Object {
    $package = $_
    $skip = $true
    $miniorBlackList | ForEach-Object {
        $miniorBlack = $_
        if($package.Id.StartsWith($miniorBlack)) {
            $skip = $false
        }
    }
    if(!$skip) {
        Write-Host "$($package.Id) $($package.CurrentVersion)->$($package.NewVersion)"
    }
}

[daTooz]

Bump +1