Add support for easier CentralPackageManagement options

[dansiegel]

Is your feature request related to a problem? Please describe.

As CentralPacakgeManagement becomes more mainstream it is something we would like to offer as an option in our templates like:

dotnet new mytemplate -cpm

Currently we would need to have dependencies in our template like:

<ItemGroup>
  <!--#if (useCentralPackageManagement)-->
  <PackageReference Include="PackageA" />
  <PackageReference Include="PackageB" />
  <!--#else-->
  <PackageReference Include="PackageA" Version="8.0.0" />
  <PackageReference Include="PackageB" Version="8.0.0" />
  <!--#endif-->
</ItemGroup>

Describe the solution you'd like.

Add a post action that can work from any host (VS/CLI/etc) which can remove versions on PackageReferences. This could be purpose build to strip out any PackageReference Version. Or to make this the most useful for a variety of situations perhaps a Regex Replace Post Action could be more useful.

"postActions": [{
  "condition": "(useCentralPackageManagement)",
  "description": "Removes the PackageReference Versions in the generated csproj.",
  "args": {
    "files": "**\\*.csproj",
    "pattern": "(\\s?Version=\\\"\\d+\\.\\d+(.\\d+)?(.\\d+)?(-[A-Za-z\\.0-9]+)?\\\")",
    "replace": ""
  },
  "manualInstructions": [{
    "text": "Remove the PackageReference Versions'"
  }],
  "actionId": "Some Id",
  "continueOnError": false
}]

Additional context

No response

[YuliiaKovalova]

Can be related to the topic:
#3208

[YuliiaKovalova]

related to dotnet/aspnetcore#48569

[YuliiaKovalova]

related to dotnet/aspnetcore#48569

[Evangelink]

@YuliiaKovalova Is there any recommended way to fix that at the moment? Given that we are less advanced on test-template side, I'd like to simply copy/follow recommendations.

[YuliiaKovalova]

@Evangelink , we are investigating the possibility of PostAction usage for resolving this issue.
I will let you know once we know more.

[YuliiaKovalova]

Hi @dansiegel , @Evangelink ,

Sorry for the long reply.
We can suggest you a workaround for handling CPM option.
You can add the needed references using Post Action.

template.json:

{
  "$schema": "http://json.schemastore.org/template",
  "author": "Microsoft",
  "name": "CPM Test Project",
  "generatorVersions": "[1.0.0.0-*)",
  "description": "Test",
  "groupIdentity": "cpm",
  "precedence": "8000",
  "identity": "CPM",
  "shortName": "cpm",
  "tags": {
    "language": "C#",
    "type": "project"
  },
  "sourceName": "Company.TestProject1",
  "preferNameDirectory": true,
  "primaryOutputs": [
    { "path": "Company.TestProject1.csproj" }
  ],
  "defaultName": "TestProject1",
  "postActions": [
    {
      "description": "Adding Reference to Microsoft.Azure.WebJobs.Extensions.DurableTask NuGet package",
      "actionId": "B17581D1-C5C9-4489-8F0A-004BE667B814",
      "continueOnError": true,
      "manualInstructions": [],
      "args": {
        "referenceType": "package",
        "reference": "Microsoft.Azure.WebJobs.Extensions.DurableTask", "version": "2.4.2",
        "projectFileExtensions": ".csproj"
      }
    },
    {
      "description": "Adding Reference to NUnit",
      "actionId": "B17581D1-C5C9-4489-8F0A-004BE667B814",
      "continueOnError": true,
      "manualInstructions": [],
      "args": {
        "referenceType": "package",
        "reference": "NUnit",
        "projectFileExtensions": ".csproj"
      }
    }
  ]
}

Company.TestProject1.csproj

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>net6.0</TargetFramework>
  </PropertyGroup>

</Project>

Directory.Packages.props

<Project>
  <PropertyGroup>
    <ManagePackageVersionsCentrally>true</ManagePackageVersionsCentrally>
  </PropertyGroup>
  <ItemGroup>
    <PackageVersion Include="Microsoft.Azure.WebJobs.Extensions.DurableTask" Version="2.4.2" />
    <PackageVersion Include="NUnit" Version="3.12.0" />
  </ItemGroup>
</Project>

Please let me know if it helps you.

[YuliiaKovalova]

Close due to the existing workaround described in #6187 (comment).

[baronfel]

I'm going to reopen this because while a workaround is useful, a proper, baked in postaction or first-class extension to the templating schema for .Net projects for managing packages would be a boon for template authors.

[baronfel]

Specific teams that want an improved experience here:

• Test (cc @Evangelink)
• Aspnet (cc @DamianEdwards)
• Aspire

[JonDouglas]

Specific teams that want an improved experience here:

• Test (cc @Evangelink)
• Aspnet (cc @DamianEdwards)
• Aspire

Speculating here but...here's more:

• EF
• NuGet (yes, we use this)
• upgrade-assistant (just added CPM support)
• etc

[seangwright]

My company is trying to establish consistent use of CPM in all of our open-source projects and encourage our developer community to use it.

This recommendation/guidance requires additional explanations of why/how dotnet new doesn't exactly work with CPM today.

It would be really nice to have the templating for templates we don't control (e.g. dotnet new nunit) and the ones we do control and publish have 1st class support for CPM.

[georgiydx]

My company (DevExpress) would also like to see improvements in this area. We're increasingly adopting central package management in our products, and want to allow it as an option for project templates as well. But the lack of built-in support for CPM is making it difficult to implement, and the suggested workarounds are too complex to maintain.

[dansiegel]

the suggested workarounds are too complex to maintain.