Templates create compile errors in solutions with Central Package Management (CPM)

[cremor]

Is there an existing issue for this?

• [X] I have searched the existing issues

Describe the bug

The project templates always add a Version attribute to the <PackageReference> items in the csproj file. This is an error when Central Package Management (CPM) is enabled.

Expected Behavior

The project templates should not add a Version attribute to the <PackageReference> items in the csproj file when Central Package Management (CPM) is enabled. If nesessary, the required <PackageVersion> items should be added to the Directory.Packages.props file.

Steps To Reproduce

1. Create or open a solution with Central Package Management (CPM)
2. Add a new project via one of the project templates that uses <PackageReference> items (e.g. by enabling individual authentication or OpenAPI support for an ASP.NET Core project).
3. Notice that there are compile errors. The root error is NU1008 Projects that use central package version management should not define the version on the PackageReference items but on the PackageVersion items

Exceptions (if any)

No response

.NET Version

7.0.203

Anything else?

Using Visual Studio 17.5.5

Related: dotnet/test-templates#300

[mkArtakMSFT]

@marcpopMSFT this seems to be a tooling ask, specifically for adding a project reference to an existing project. Can you please direct this to the right owners? Thanks!

[marcpopMSFT]

CC @JonDouglas @baronfel this seems like a reasonable ask of the dotnet add package command but this specific issue is about templates. This would be a feature request on the template engine for templates to support CPM and have dotnet detect CPM and pass a default value through to the template that controlled the PackageReferences included based on that value.

[baronfel]

I agree it's a template-engine area concern - we have some larger-scale questions about how Packages are managed in templates. Most folks have hardcoded PackageReferences, so either the entire package ecosystem needs to update templates to conditionally-set versions, or we need to do something more first-class in the engine.

[baronfel]

If these were item templates (i.e. a project already existed) then we could use a bind symbol to check if the project supported CPM and then change the template content based on that, but instead we probably need to actually do work here.

[cremor]

So should this issue be transferred to https://github.com/dotnet/templating? If yes, could someone please do that?

[YuliiaKovalova]

To begin with this issue - validate if existing post action "B17581D1-C5C9-4489-8F0A-004BE667B814" (Add reference - adds a reference to a project, package or framework assembly.) helps to workaround this issue for different cases: the version specified in post action + cpm enabled the version specified in post action + cpm disabled no version + cpm enabled.

[YuliiaKovalova]

Hi @cremor,

In order to workaround this problem you need to change templates according to recommendation, that is described here: https://github.com/dotnet/templating/issues/6187#issuecomment-1572223281 .

Please let me know if it helps you to resolve the issue.

[cremor]

@YuliiaKovalova I'm not a template author. I initially created this issue in the dotnet/aspnetcore repository. It was specific about the ASP.NET Core project templates. But then it was moved to other repositories, see comments above.

So if you think that this is not a general templating engine issue, then it should be moved back to dotnet/aspnetcore.

[YuliiaKovalova]

Hi Team,

The mentioned template requires some adjustments for supporting CPM: https://github.com/dotnet/templating/issues/6187#issuecomment-1572223281 . Templates can work with it through the post-action.

If you need any help from our team, feel free to tag me.

[ghost]

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

[mkArtakMSFT]

Discussed this with @DamianEdwards and here are some notes from our conversation (thanks Damian 👍).

If we implement this experience as is, scaffolding will not work properly (Adding Identity to an existing project will most probably add the hardcoded package reference to the project file). Hence, this should be implemented in a coordinated manner with support of all the following teams: NuGet, Templating Engine, Web Tools and template owners.

For now, this is not on our critical path for .NET 8 deliverables, so I've pushed this out from .NET 8. @YuliiaKovalova if you believe this should be reprioritized and above-mentioned coordination is already in progress, please reach out (I will most probably miss GitHub notifications) and let's talk.

[YuliiaKovalova]

Hi @mkArtakMSFT,

The Template Engine crew is ok with your plans.