Support filtering on nuget's PackageReference VersionOverride attribute

[AArnott]

In a repo that uses Directory.Packages.props for centralized version control, an individual project may still override individual versions using a VersionOverride attribute:

<PackageReference Include="Microsoft.VisualStudio.Extensibility" VersionOverride="17.13.2060" />

Renovate apparently recognizes this and offers to update them. Which is fine, perhaps in some cases. But in our cases we override them with very specific intent and never want those updated.
I don't see any way to filter/match based on this attribute being used, however.

Can a way be added so that we can always retain VersionOverride values via configuration?

Repro repo

[slonim-greg]

To voice our support for this feature and give some context for our use case (we also use Microsoft CPM)

We have some legacy code that has yet to be moved from Net60. Therefore, we have these conditional dependency blocks:

<ItemGroup Condition="'$(TargetFramework)' == 'net8.0'">
      <PackageReference Include="HotChocolate.AspNetCore" />
      <PackageReference Include="Microsoft.Data.SqlClient" />
</ItemGroup>
 <ItemGroup Condition="'$(TargetFramework)' == 'net6.0'">
      <PackageReference Include="HotChocolate.AspNetCore" VersionOverride="14.3.0"/>
      <PackageReference Include="Microsoft.Data.SqlClient" VersionOverride="6.0.1"/>
       ... 
</ItemGroup

While we totally want our Directory.Packages.Props to be scanned and upgraded, we do need to pin the VersionOverride statements.

Please share your thoughts on this.

[AArnott]

I have a workaround:

  "nuget": {
    "ignorePaths": ["**/*.csproj"]
  }

This works because I use Directory.Packages.props, so the only versions in csproj's would be VersionOverride properties.

[slonim-greg]

Do you have this inside packageRules ?

[github-actions[bot]]

Hi there,

Please help this Discussion progress by creating a minimal reproduction. This means a repository dedicated to reproducing this issue with the minimal dependencies and config possible.

Before we start working on your issue we need to know exactly what's causing the current behavior. A minimal reproduction helps us with this. Discussions without reproductions are less likely to be converted to Issues.

Please follow these steps:

1. Read our guide on creating a minimal reproduction.
2. Go to our minimal reproduction template repository.
3. Select the Use this template button to create a new repository based on the template.
4. Work on the minimal reproduction in your own repository.
5. Fill out the information in your repository's README.md.
6. Add the link to your reproduction to the first post of your Discussion. If you are not the original author, you can post a new comment with the link.

If you need help with running renovate on your minimal reproduction repository, please refer to our Running Renovate guide.
Good luck,

The Renovate team

[AArnott]

As this is a feature request and not a bug report, I'm not sure how to create a repro... since the scenario simply isn't supported today.
I think between my OP and @slonim-greg's example, this is covered.

[rarkins]

Both features and bug fixes should be tested on real repos once done. So a reproduction repo is still needed - one which shows the type of repo not handled today with a resume describing desired outcome.

[AArnott]

repro repo link added to the OP.