Templating: Update an already installed template

[panmau]

What is is the best way to update an already installed template? (NuGet or File distribution)
Should the template be uninstalled and then the new version installed again?

There doesn't seem to be a --update flag

[seancpeters]

@maracuja-juice you can just install the newer version directly, either from nuget or from your local FS. When installing a template pack, if there is already an installed version of the same templates, the templates being installed overwrite the ones already installed.

[panmau]

Okay that makes sense!

[panmau]

For me it doesn't overwrite the template but installs it as a new one.
When I do dotnet new -u I see the same package twice in the list. @seancpeters

[seancpeters]

@maracuja-juice could you post the output of dotnet --info?

There was a bug in a couple versions of dotnet new that exhibit behavior similar to what you're reporting here.

[panmau]

This is the output @seancpeters

.NET Core SDK (reflecting any global.json):
 Version:   2.1.300-rc1-008673
 Commit:    f5e3ddbe73

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.17134
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\2.1.300-rc1-008673\

Host (useful for support):
  Version: 2.1.0-rc1
  Commit:  eb9bc92051

.NET Core SDKs installed:
  2.1.4 [C:\Program Files\dotnet\sdk]
  2.1.105 [C:\Program Files\dotnet\sdk]
  2.1.200 [C:\Program Files\dotnet\sdk]
  2.1.300-rc1-008673 [C:\Program Files\dotnet\sdk]

.NET Core runtimes installed:
  Microsoft.AspNetCore.All 2.1.0-rc1-final [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.1.0-rc1-final [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 2.0.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.0.7 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.0-rc1 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]

[mlorbetske]

@maracuja-juice could you add the command that you used to install the package each time and the output of dotnet new -u as well please? Also, if the package you're installing is available, it'd be helpful for us to be able to take a look at that as well

[panmau]

@mlorbetske
Normal dotnet new -i Template.Package.Name
and in dotnet new -u I see:

 Microsoft.DotNet.Common.ItemTemplates
 Microsoft.DotNet.Common.ProjectTemplates.2.1
 Microsoft.DotNet.Test.ProjectTemplates.2.1
 Microsoft.DotNet.Web.ItemTemplates
 Microsoft.DotNet.Web.ProjectTemplates.2.1
 Microsoft.DotNet.Web.Spa.ProjectTemplates
 Template.Package.Name
 Template.Package.Name
 Template.Package.Name

[mlorbetske]

Interesting, this looks like the issue where a new mapping is created for the installed item even if it existed before. @seancpeters did you get a chance to confirm that this was that issue and/or whether it’s already fixed?

[tidyui]

I've reproduced this bug as I'm deploying project templates for @piranhacms using NuGet. It seems as

dotnet new -i MyNuGetPackage

installs the package from the local NuGet cache if it's available there. The combination of the following lines installs the new version of the project template for me.

dotnet nuget locals all --clear
dotnet new -i MyNuGetPackage

If my observation is correct it of course feels like the correct behavior would be to always install from package source as there's no way of specifying which version to install from dotnet new -i.

[mlorbetske]

@tidyui you can specify the version to install as dotnet new -i MyNuGetPackage::version. The installer doesn't look for the package in the NuGet cache vs the configured package sources explicitly, it generates a project file with the package ID and version (if no version was specified, it uses *), calls dotnet restore on that project and specifies a location to place the restored packages and then looks at the packages in that location for templates. The code for the installer is here if you're interested in seeing how it works.

[mlorbetske]

Related #1423

[panmau]

Related #1645

[panmau]

@mlorbetske What if I just want to install the newest version that is available in the source without explicitly specifying the version? (Fe: cause it would need time to look it up or I have a script that does update all my packages regularly) / Any update on this?

[tillig]

Scenario: We have an internal template published at version 0.3.0. A fix is made, version 0.3.1 gets published.

When 0.3.0 is published, it gets installed with dotnet new -i TemplatePackage --nuget-source https://our.internal.nuget.server.

Now 0.3.1 is published. Running dotnet new --update-check does not find version 0.3.1. Running dotnet new --update-check --nuget-source https://our.internal.nuget.server also does not find version 0.3.1. Trying to install using the above -i command does not find the new version.

To upgrade, you have to flush the NuGet cache and then manually install again, which will pick up the new version and update.

dotnet nuget locals all --clear
dotnet new -i TemplatePackage --nuget-source https://our.internal.nuget.server

It seems like --update-check isn't doing what it says on the tin; and if you use -i it should logically check the package source first, rather than the cache.

[dannyyy]

I'm experiencing the absolute same behaviour as @tillig do.
Please fix this as soon as possible. All these workarounds aren't very convenient in everyday life.

This is what I do (other workaround)

dotnet new -u MyPackage
dotnet new -i MyPackage --nuget-source https://myfeed.tld/feed.json

[MikeRosoft]

But as other users mentioned, the dotnet new -i command first checks the cache, so you have to do:

dotnet new -u PackageName
nuget locals http-cache -clear
dotnet new -i PackageName

[donJoseLuis]

@grinrag let's look at this for a short-term fix

[jstafford5380]

If I try to update by doing dotnet new -i <package name> it does not replace with the newest version

If I try to update by doing `dotnet new -i :: then i get a message saying that it could not find that versions

If I try to update by doing `dotnet new -i :: --nuget-source then I still get a message saying that it could not find that version

If list with nuget list <package> -s <source> then it shows the latest package, so I know it's there and indexed/available

If uninstall the package, clear the local nuget cache, and then install dotnet new -i <package name> then it installs the correct version.

[donJoseLuis]

@jstafford5380 greetings. Thanks for the update, we classified this one as an item we will look at soon.
We are trying to get to know template engine users. If you're interested, we'd like to know more about how you specifically use the engine.

[donJoseLuis]

@grinrag let's discuss this one again in the next triage.

[jstafford5380]

@jstafford5380 greetings. Thanks for the update, we classified this one as an item we will look at soon.
We are trying to get to know template engine users. If you're interested, we'd like to know more about how you specifically use the engine.

Sure let me know of any specific questions you have. In short, we have a growing micro/mini-service platform, so we spin up new projects often. We are developing one or more templates that fit our standards, but at the moment, they are being updated somewhat often as we learn more about how we want it to work with other elements of the system, so it's important that I can push a new template pack to our private nuget server (azure devops artifacts) and inform the teams that the newest template is available. Following the notification, the expectation is that all they have to do is run a quick command to update their template pack so that it is available the next time they need to spin up a new project.

In the mid to long-term, we have plans to create a developer self service portal that will also need these templates. The expectation is that a developer will ask the portal to provision a new project with a set of parameters (project name, project type, labels, etc.). The build or config server would quickly update its templates, create the new project from the template, create the repo, do the initial commit, notify the build server of the new project to create the pipeline, run the service provisioning in azure, run the build and get a running service up in all environments, and notify the developer so they can pull the code down and begin work.

[kvpt]

I have the same issue.
I publish a new version of the template and no update is detected.
And if I try to force the version

dotnet new -i MyTemplate::LatestVersion

For each nuget sources, it say : error NU1102 version not found
And if I use

--update-check

It say : No updates were found.

So there is a problem with the cache invalidation/update somewhere.

I use it since two years now it this bug is present since the beginning for me.
The only solution is like @jstafford5380 say to manually clean the nuget cache.

I also remarked that the problem only occur if the package is very recent, if I wait 15 minutes and retry to force the version, it found it.
So I really think that the issue is related to the cache management in nuget.

[brettrowberry]

Related #2398

[kriscoleman]

Would still love to have this addressed.

It seems silly that every time my team publishes a new version of our dotnet new templates, we have to notify everyone, and run two commands. One to clear the cache, and then the install command again.

It would be nice if we could simply avoid the cache with a --update as has been suggested.
We could rectify this with a bash alias or something (in fact might do this as a workaround) but it just feels so silly.

[nonniv]

--update-apply

[vlada-shubina]

The fix will be delivered in https://github.com/dotnet/templating/issues/2592.

[softwaretirol]

We have a workaround for our team:

DEL /F/Q/S %USERPROFILE%\AppData\Local\NuGet\v3-cache\
dotnet new -i <MyPackageId> --nuget-source https://<MyPackageFeed> --force

[vlada-shubina]

We implemented check via NuGet API (available in main branch), now the update information is available immediately (via --update-check and --update-apply commands).
Also API is forced not to use cache, so issue of local NuGet cache being old also eliminated (more details in https://github.com/dotnet/templating/issues/2874).

Closing this issue.