.NET templates shouldn't move forward for end-of-support versions

[mattchenderson]

This item is to be treated as an investigation, and it likely needs to be broken into multiple sub-items.

We need to update our templates to use more modern versions of C#, but we need that not to impact older TFMs that could still be in use. An example of this is primary constructors (see Azure/azure-functions-templates#1716)

Our plan is to allow the template packages to move forward, but to try where possible to preserve (and freeze) the existing template experience for out-of-support versions. An example of this can be found in this tooling feed update: Azure/azure-functions-tooling-feed#625

As a principle, we should avoid hard-coding of versions for TFMs, etc.

This work should encompass updates to pipelines and to team process documentation.

[mattchenderson]

Brainstorming one design option (not prescriptive; investigation should explore other options)

One option to explore here would be to take a dependency on the tooling feed as part of the Core Tools, perhaps for out-of-support versions only. We still might like to cut a core tools update and push it to latest packages even if the feed has not yet been updated - we don't want a situation where we have to do multiple feed releases to first have templates and then have the Core Tools. In general, we need the flexibility to override.

It seems like it would make sense to bring this as part of the build process, perhaps replacing the hard-coded values provided as default parameters:

azure-functions-core-tools/eng/scripts/download-templates.ps1

Lines 13 to 17 in a945aaf

	param (
	[string]$OutputPath = "./templates-download",
	[string]$TemplatesVersion = "4.0.5337",
	[string]$TemplateJsonVersion = "3.1.1648"
	)

The semantics of those parameters could be scoped to in-support versions. But the feed could still be relied upon for older versions, unless some new override were provided.

To avoid bloating the Core Tools, anything other than the primary included version could be dynamically resolved as needed, meaning a func init or func new would pull the package only when invoked in the context of an old TFM, assuming this has not already been done. The Core Tools would just need to carry the pointer to the version. To do something like this, we would need to add some extra handling for offline execution - falling back to the newer built-in templates with a warning may be appropriate.

[liliankasem]

Just FYI, the script you mention download-templates.ps1 is not used by core tools at all - this is just a handy script to install templates manually if needed.

Templates packaged with core tools today are controlled via targets during the build process:

https://github.com/Azure/azure-functions-core-tools/blob/main/eng/build/Templates.targets