Package downgrade warnings from NuGet due to renovate PR

[AArnott]

How are you running Renovate?

Self-hosted Renovate

If you're self-hosting Renovate, tell us which platform (GitHub, GitLab, etc) and which version of Renovate.

Azure DevOps
[email protected]

Please tell us more about your question or problem

A renovate PR proposes this change to Directory.Packages.props:

    <PackageVersion Include="Microsoft.ServiceHub.Framework" Version="4.5.35" />
    <PackageVersion Include="Microsoft.VisualStudio.Sdk.TestFramework.Xunit" Version="17.6.32" />
-   <PackageVersion Include="Microsoft.VisualStudio.Sdk.TestFramework" Version="17.6.32" />
+   <PackageVersion Include="Microsoft.VisualStudio.Sdk.TestFramework" Version="17.11.25" />

But the PR validation fails due to a NuGet package downgrade warning:

D:\a\_work\1\s\test\Microsoft.VisualStudio.RpcContracts.Tests\Microsoft.VisualStudio.RpcContracts.Tests.csproj : error NU1605: Warning As Error: Detected package downgrade: Microsoft.ServiceHub.Framework from 4.6.12-preview to 4.5.35. Reference the package directly from the project to select a different version.  [D:\a\_work\1\s\Microsoft.VisualStudio.RpcContracts.sln]
D:\a\_work\1\s\test\Microsoft.VisualStudio.RpcContracts.Tests\Microsoft.VisualStudio.RpcContracts.Tests.csproj : error NU1605:  Microsoft.VisualStudio.RpcContracts.Tests -> Microsoft.VisualStudio.Sdk.TestFramework 17.11.25 -> Microsoft.VisualStudio.Utilities 17.11.39607 -> Microsoft.ServiceHub.Framework (>= 4.6.12-preview)  [D:\a\_work\1\s\Microsoft.VisualStudio.RpcContracts.sln]
D:\a\_work\1\s\test\Microsoft.VisualStudio.RpcContracts.Tests\Microsoft.VisualStudio.RpcContracts.Tests.csproj : error NU1605:  Microsoft.VisualStudio.RpcContracts.Tests -> Microsoft.VisualStudio.Sdk.TestFramework 17.11.25 -> Microsoft.ServiceHub.Framework.Testing 4.4.22 -> Microsoft.ServiceHub.Framework (>= 4.5.35) [D:\a\_work\1\s\Microsoft.VisualStudio.RpcContracts.sln]

Is there a way to configure renovate to realize this and bump additional package versions as necessary to avoid this break?

Logs (if relevant)

No response

[rarkins]

How could renovate know to do that? Eg is this a matter of grouping other updates together to a single PR?

[AArnott]

To avoid the errors/warnings, renovate would either have to avoid updating one dependency until the other dependency had been updated, or it would have to group them together.
It wouldn't be reasonable to require the repo to configure this grouping themselves because it isn't a well-known and well-defined set. It's a dependency tree which can change shape with each version of each package. So instead, renovate would have to dynamically determine the groups.

Suppose a repo had these dependencies with versions explicitly stated (whether all in Directory.Packages.props or individually in csproj files, doesn't matter):

A: 1.0
B: 1.5

Now, renovate comes along and wants to update to A 1.1, which happens to have this dependency relationship:

flowchart LR
    A["A 1.1"] --> B["B 1.6"]

Loading

Renovate can discover this simply by looking at A.nuspec. So it may now deduce that it can freely update B to 1.6 alone, or it can update A and B together. But updating A alone is going to fail so that PR should never be created.

This is the simplest example. It's also conceivable that the relevant relationship is transitive:

A: 1.0
C: 4.5

flowchart LR
    A["A 1.1"] --> B["B 1.6"]
    B --> C["C 4.8"]

Loading

In which case, updating A to 1.1 and looking at its .nuspec won't alone reveal the problem, since B updating to 1.6 doesn't apparently conflict with any version specs in the repo. But if renovate downloaded the tree of packages of A 1.1 and inspected all the nuspec files, it would see that C would be in a conflicted state and therefore A cannot be updated without also updating C.

[viceice]

this isn't as easy as you think. the big issue is that those references nuspec are behind multiple dotnet tfms and they can be different for different tfms.

this is also an edge case which resolves itself. after merging the appropriate dependency

[AArnott]

True, the TFMs can complicate it, for sure. You could try to keep things simpler by assuming all TFMs apply and taking the union of their dependencies. There are probably edge cases there when different target frameworks have different versions of the same dependencies, but that would be really unusual.

As for my initial problem being an edge case, I'm afraid that's far from my experience. In repos with many projects, package downgrade warnings can be the result of well more than half of the PRs that renovate creates. One of renovate's value props for me is wins in productivity as I can simply review and merge version upgrades. But if most of those PRs are broken, and I have to go through all 10 to find the 2 that 'work', and then tell renovate to rebase the rest to see what the next level is that works, rinse and repeat until all the PRs finally pass and are merged, that erodes the value prop.

BTW, in case it's useful, I have a tool (repo nuget reconcile-versions in the DotNetRepoTools) that can automatically fix these things. So if for example renovate were to bump A, causing a package downgrade warning for B and/or C, my tool will automatically bump B and/or C as necessary to eliminate the warnings. Then renovate could proceed to create the PR. Without an automated tool like renovate, this is how I would do it by hand to save myself the trouble of having to keep bumping version after version until all the warnings/errors go away.