Templates: Add optional Central Package Management support to UmbracoProject and UmbracoExtension templates

[NguyenThuyLan]

Description
Idea: #21333

• Adds a --PackageManagement (-P) template parameter with two choices: PerProject(default) and Central, allowing users to opt into
  https://learn.microsoft.com/en-us/nuget/consume-packages/central-package-management when scaffolding new projects
• When "Central" is selected, a Directory.Packages.props file is generated and .csproj package references omit version attributes; when "PerProject" is
  selected (default), the existing behavior is preserved with versions inline in the .csproj
• Applies to both the UmbracoProject and UmbracoExtension templates, with the extension template additionally enabling
  CentralPackageFloatingVersionsEnabled so extensions can align with the host project's package versions.

Nuget package versions per project
dotnet new umbraco -pm PerProject or dotnet new umbraco-extension -pm PerProject
With Central Package Management (default)
dotnet new umbraco
Extension with CPM (default)
dotnet new umbraco-extension

Test plan

• Run dotnet new umbraco -pm PerProject and verify no Directory.Packages.props is created, .csproj has versions inline
• Run dotnet new umbraco (default) and verify Directory.Packages.props is generated, .csproj has no version attributes
• Run dotnet new umbraco-extension -pm PerProject and verify no Directory.Packages.props is created, .csproj has versions inline
• Run dotnet new umbraco-extension(default) and verify CPM output with CentralPackageFloatingVersionsEnabled
• Verify dotnet build succeeds for generated projects in both modes

[AndyButland]

This looks good @NguyenThuyLan, but I'm having trouble testing it. I think it's a problem on my side, as I have the same problem when I test from main. But can you see what I'm missing please?

• From the root of the solution I'm running dotnet pack -c Release -o "c:\repos\nuget\"
• Then from a folder where I want to install the test site I'm running:

dotnet new uninstall Umbraco.Templates
dotnet new install "c:\repos\nuget\Umbraco.Templates.17.3.0--rc.preview.26.gdfb46be.nupkg"
dotnet new umbraco --name Test17
cd .\Test17\

Here I add a NuGet.config file with:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageSources>
    <clear/>
    <add key="nuget.org" value="https://api.nuget.org/v3/index.json" />
    <add key="Local Feed" value="c:\repos\nuget\" />
  </packageSources>

  <activePackageSource>
    <add key="All" value="(Aggregate source)" />
  </activePackageSource>

</configuration>

• And then dotnet run

Umbraco will then build and run, but I don't get the install screen come up and all static assets requested are returning 404.

[NguyenThuyLan]

Oh, I got the same issue, @AndyButland the reason is that you forgot to run npm ci && npm run build:for:cms for Umbraco.Web.UI.Client and npm run build for Umbraco.Web.UI.Login.

Follow these steps:

1. Check the wwwroot\umbraco folder in Umbraco.Cms.StaticAssets to see if there are two folders named backoffice and login. If so, delete them and run the above commands again for Client and Login project.
2. These two commands will re-render the new data for the backoffice and login folders.
3. Run again dotnet pack -c Release -o "c:\repos\nuget\"
4. Install the template adn then install a new project from the template. It will then load CSS and JS files successfully

[AndyButland]

Thanks @NguyenThuyLan - I still couldn't get it working from a local dotnet pack but I realised I could download the NuGet files built as part of this PR, so I did that. And can confirm it all works as expected. The instructions on how to use and manage packages using CPM are very good too.

Let's pause to get @LottePitcher and @nul800sebastiaan's feedback on whether this should be applied to the extension template too.

As you noted:

I only added CPM to UmbracoProject, not UmbracoExtension. This avoids potential merge conflicts if users add an extension project to an existing Umbraco solution.

For new projects, and consistency though, it would make sense to use the Directory.Packages.props approach in the extensions template too.

From my side I just wondered if this should be (or could be?) an option - so the user of the template has the option to decide which package management approach they want. Maybe you could consider how feasible that is.

[NguyenThuyLan]

@AndyButland , Oh I think that's a good idea. What about adding a PackageManagement parameter with two choices

• Traditional (default): Package versions in .csproj
• Central: Uses Directory.Packages.props
  Then the user can choose how to use CPM by running:
  dotnet new umbraco-extension -n MyExtension -P Central

[AndyButland]

Let's try it - at least see if it works and doesn't make the template too complicated. It should consistent for the project and extension template though - so the option should exit for both.

Sounds to me that it's nice to be an option, and also doesn't "break" anything for people that are using it.

* Of course it's not breaking in the normal sense, as templates are for new projects, but it might change expectations for people using it, or new projects spun up on Umbraco Cloud, if we make CPM the default.

[NguyenThuyLan]

I updated my PR and also the description to add this parameter option.
@AndyButland

[AndyButland]

I like that this is an option now @NguyenThuyLan, and consistent for both templates.

I think we should align the naming of the parameter with other ones, and ensure it's exposed to the CLI. So we have -p and --package-management (aligning for example with -da and --use-delivery-api in casing),

templates/UmbracoProject/.template.config/dotnetcli.host.json — add entry in symbolInfo:

"PackageManagement": {
   "longName": "package-management",
   "shortName": "pm"
 }

templates/UmbracoExtension/.template.config/dotnetcli.host.json — same entry:

 "PackageManagement": {
   "longName": "package-management",
   "shortName": "pm"
 }

I think "Traditional" as a name might not be the best (someone unfamiliar with CPM may not understand what "traditional" means in this context). Shall we go with "PerProject" instead?

Although the information in readme.md is useful, I think we can remove it now we've made CPM an option. We can safely assume that someone opting into this will be familiar with the feature. Also, as we are only explaining this single feature and not the template as a whole, it sems a bit odd to include.

[AndyButland]

All looks good to me now, thanks @NguyenThuyLan.

@nul800sebastiaan and @LottePitcher - as you raised and/or had comments on the discussion that led to this update, before we merge this, please could you have a look over to make sure it meets your expectations?

[LottePitcher]

There is an issue at the moment if you call the template with the combination of -pm Central -r LTS - i.e. central package management whilst specifying to use the LTS release.

If you do that, then Directory.Packages.props is generated as:

<Project>
  <PropertyGroup>
    <ManagePackageVersionsCentrally>true</ManagePackageVersionsCentrally>
  </PropertyGroup>
  <ItemGroup>
    <PackageVersion Include="Umbraco.Cms" Version="17.*" />
    <PackageVersion Include="Umbraco.Cms.DevelopmentMode.Backoffice" Version="17.*" />
    <PackageVersion Include="Microsoft.ICU.ICU4C.Runtime" Version="72.1.0.3" />
  </ItemGroup>
</Project>

This fails as floating versions aren't allowed with CPM:

error NU1011: The following PackageVersion items cannot specify a floating version: 
Umbraco.Cms, Umbraco.Cms.DevelopmentMode.Backoffice. 
For more information on how to enable this functionality for projects using Central Package Management, visit https://aka.ms/nu1011

Now whether anyone would actually do this combination I don't know.

It's fixed by adding to Directory.Packages.props this line:

<CentralPackageFloatingVersionsEnabled>true</CentralPackageFloatingVersionsEnabled> to the file

@NguyenThuyLan I can see you have already added this flag to the file in the Extensions template.

Should we enable floating versions on the Umbraco project template too? Or let people figure their own work around if they do choose this combination and generate the error?

[AndyButland]

Should we enable floating versions on the Umbraco project template too? Or let people figure their own work around if they do choose this combination and generate the error?

For the project template I think we have to do everything we can that this "just works". The extension is for more advanced developers, who perhaps can figure things out, but the project one is the way to install Umbraco for everyone.

So I think this either has to work with floating versions - which would be ideal - or we install specific versions of 17 (and have to make sure we update the template with the latest 17 version every time we release an update of that major).

[NguyenThuyLan]

Thank you @LottePitcher for pointing that out.
I have updated the template.json and Directory.Packages.props files. The project will be created using CPM by default.
Description of this PR was updated, too.

[AndyButland]

I realise I'm not seeing the option presented for selection when I try to use the template in Visual Studio @NguyenThuyLan - I would have expected to see it here:

It looks like entries in the two ide.host.json files are missing.

[AndyButland]

Works nicely from the command line - I've created projects with both options and they are setup as expected and build and run fine.

I realise I'm not seeing the option presented for selection when I try to use the template in Visual Studio though @NguyenThuyLan - I would have expected to see it here:

It looks like entries in the two ide.host.json files are missing.

[NguyenThuyLan]

Yes, I updated ide.host.json files, now we can choose Package Version Management in Visual studio when creating projects

[AndyButland]

Looks good and works nicely now @LanThuyNguyen - I've tested the various configurations via the CLI and IDE, I'm seeing the expected projects generated, and have verified that they build.