dotnet add package with CPM installs a different version than what gets restored

[vernou]

NuGet Product Used

dotnet.exe

Product Version

8.0.7

Worked before?

No response

Impact

It bothers me. A fix would be nice

Repro Steps & Context

1. Create in a empty folder the file the Directory.Packages.props to Package Management specify [email protected] :

<Project>
  <PropertyGroup>
    <ManagePackageVersionsCentrally>true</ManagePackageVersionsCentrally>
  </PropertyGroup>

  <ItemGroup>
    <PackageVersion Include="Azure.Identity" Version="1.10.3" />
  </ItemGroup>
</Project>

2. Create a project with the package Azure.Identity without specify the version and audit it :

dotnet new console -n ConsoleApp1
dotnet add ConsoleApp1 package Azure.Identity
dotnet list ConsoleApp1 package --vulnerable

The audit show no vulnerability :

The given project `ConsoleApp1` has no vulnerable packages given the current sources.

3. Restore the project and reaudit it :

dotnet restore ConsoleApp1
dotnet list ConsoleApp1 package --vulnerable

The audit show the expected vulnerabilities :

Project `ConsoleApp1` has the following vulnerable packages
   [net8.0]:
   Top-level Package      Requested   Resolved   Severity   Advisory URL
   > Azure.Identity       1.10.3      1.10.3     Moderate   https://github.com/advisories/GHSA-wvxc-855f-jvrv
                                                 Moderate   https://github.com/advisories/GHSA-m5vv-6r4h-3vj9

---

Without CPM, the audit work without restore :

dotnet new console -n ConsoleApp1
dotnet add ConsoleApp1 package Azure.Identity --version 1.10.3
dotnet list ConsoleApp1 package --vulnerable

So the audit show the expected vulnerabilities :

Project `ConsoleApp1` has the following vulnerable packages
   [net8.0]:
   Top-level Package      Requested   Resolved   Severity      Advisory URL
   > Azure.Identity        1.10.3          1.10.3       Moderate   https://github.com/advisories/GHSA-wvxc-855f-jvrv
                                                                        Moderate   https://github.com/advisories/GHSA-m5vv-6r4h-3vj9

---

I expect the audit work without a explicit restore.

Verbose Logs

No response

[Nigusu-Allehu]

I have just worked on reproducing this again. This won't reproduce if the dotnet add package command is used to add a package as it will restore the project after adding the package. However, it does reproduce if the package was added manually to the csproj.

[vernou]

@Nigusu-Allehu

Weird, I reproduce with dotnet add package and CPM.
I use the dotnet SDK 8.0.303.

---

After dotnet add ConsoleApp1 package Azure.Identity, project.assets.json show :

{
  "version": 3,
  "targets": {
    "net8.0": {
      "Azure.Identity/1.12.0": {
        ...
      }
      ...
    }
  }
}

After dotnet restore, project.assets.json show :

{
  "version": 3,
  "targets": {
    "net8.0": {
      "Azure.Identity/1.10.3": {
        ...
      }
      ...
    }
  }
}

I think the dotnet add package ignore CPM and install the last version.

---

If you want, I can try to fix it?

[zivkan]

@vernou thank you for noticing this! With the C# DevKit installed in VSCode, it's harder to notice, because it will automatically restore the project, so trying to view the assets file in VSCode is harder 🤦

If you'd like to contribute a fix, that will be fantastic. The code is in our src\NuGet.Core\NuGet.CommandLine.XPlat project. You'll need to uncomment some lines from the csproj and Program.cs in order to be able to debug that project, and as you start trying to debug, you'll see you need to order the app's arguments slightly differently to how you do with the dotnet CLI. Hopefully that's enough to get started.

I've also created a second issue, which will help understand the scenario when the project is hand-edited without restoring:

• dotnet list package should warn when restore is not current #13703

If you (or any other community member) cannot fix this soon, I'll probably end up trying to do it myself in September.

[vernou]

@zivkan, I created the draft PR NuGet/NuGet.Client#5982.
It miss the test, but can you check if I'm on the right track?

[zivkan]

There's a decent chance that this fix makes it into the 9.0.100 SDK, but a small chance it'll slip to 9.0.200