[Bug]: Centralized Package Versioning causes NU1008 from included .targets files using non-centralized PackageReferences

[dtarjeft]

NuGet Product Used

dotnet.exe, MSBuild.exe, NuGet.exe

Product Version

dotnet 6.0.302, msbuild 16.11.2.50704, nuget 6.2.1.2

Worked before?

New issue encountered in upgrade process

Impact

I'm unable to use this version

Repro Steps & Context

1. Create a C# project.
2. Set up Centralized Package Versioning
3. Install a package that contains a .targets file that has a PackageReference in it. Example of a .targets file that causes the issue:
   
4. Attempt to build.

What I expected:
A build that successfully handles the PackageReference's .targets' dependencies.

What I got:
NU1008, due to the referenced target file having declared a version.

This is a blocker for my team's adoption of CPVM, as any build helpers we have installed become build stoppers.

Verbose Logs

No response

[nkolev92]

Hey @dtarjeft

Packages must not include restore affecting items/props in the build props and targets.

I imagine this isn't something you are seeing on the commandline just in Visual Studio?

I just created a pull request improving the docs and specifically calling out scenarios such as this: NuGet/docs.microsoft.com-nuget#2807.

[dtarjeft]

@nkolev92 Both command line and VS show NU1008. On the command line, it fails the build. In VS, it causes the projects to reload continuously.

[nkolev92]

I synced offline with @dtarjeft.

The target is not coming from a package, but rather just shared infrastructure.

[nkolev92]

Team Triage: @jeffkl can you please take a look and let us know what your recommendations are.

[jeffkl]

@dtarjeft any PackageReference declared in your project or an import must not declare a version and instead a PackageVersion should be declared in Directory.Packages.props. If that will not work for your scenario, you can do one of the following:

• Use VersionOverride to have a single PackageReference declare a version without NuGet considering it a problem
• Disable central package management for the project and every PackageReference for that project will need to specify a version.

[dtarjeft]

The first option isn't possible for my use case, as the package reference is in a referenced package. I'll give the second option a whack, although it seems to undercut the intent of the feature a little bit. Thank you for your help!

…

On Fri, Jul 29, 2022, 12:33 PM Jeff Kluge ***@***.***> wrote: @dtarjeft <https://github.com/dtarjeft> any PackageReference declared in your project or an import must not declare a version and instead a PackageVersion should be declared in Directory.Packages.props. If that will not work for your scenario, you can do one of the following: - Use VersionOverride <https://docs.microsoft.com/en-us/nuget/consume-packages/central-package-management#overriding-package-versions> to have a single PackageReference declare a version without NuGet considering it a problem - Disable central package management for the project and every PackageReference for that project will need to specify a version. — Reply to this email directly, view it on GitHub <#11967 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACJXPZPP5JEZ3T57EZATIPDVWQBVXANCNFSM53QFSQOQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[nkolev92]

@dtarjeft

The first option isn't possible for my use case, as the package reference
is in a referenced package

That's not going to work on the commandline. Packages must not add PackageReference items in their own build targets as it'd make restore inconsistent.
https://docs.microsoft.com/en-us/nuget/concepts/msbuild-props-and-targets#guidance-for-the-content-of-msbuild-props-and-targets

[dtarjeft]

@nkolev92 makes sense, I'll send that documentation to the publishers of the package. Is there a recommended approach for using a nuget reference in that context?

[nkolev92]

If a package wants another package to be installed as well, it should declare it as a dependency.

Alternatively, that package could be changed to an SDK package that'd be installed in a completely different way, https://github.com/microsoft/MSBuildSdks, and not as a PackageReference.