Templating workflows broken for paths with special characters on MacOS since SDK 9.0.200

[mattchenderson]

Describe the bug

Starting with .NET 9 SDK 9.0.200, dotnet new install seems to be treating paths differently on MacOS such that the command no longer operates as expected. The user gets an error that the package (the name of which has been normalized) is not supported.

This led to an issue with the Azure Functions Core Tools, which uses dotnet new behind the scenes. That issue is here for reference: Azure/azure-functions-core-tools#4399

The exact same gestures work fine with SDK 9.0.102.

To Reproduce

1. On MacOS using Apple Silicon, install .NET SDK 9.0.200 or later.
2. Create a path that includes an@ character:
   a. mkdir repro@4
3. Put a copy of any templating package into that folder:
   a. dotnet new console
   b. dotnet add package Microsoft.Azure.Functions.Worker.ProjectTemplates -v 4.0.5086 --package-directory ./repro@4
4. Install that package with dotnet new install using the absolute path to it:
   a. dotnet new install ./repro@4/microsoft.azure.functions.worker.projecttemplates/4.0.5086/microsoft.azure.functions.worker.projecttemplates.4.0.5086.nupkg

The Azure Functions Core Tools issue referenced above provides an alternative set of repro steps, in context. That issue is unfortunately compounded by that tool swallowing the error from dotnet new install, but the notes there may be helpful as well.

Exceptions (if any)

dotnet new --install "/usr/local/Cellar/azure-functions-core-tools@4/4.0.7030/templates/net-isolated/projectTemplates.4.0.5051.nupkg" -v diag
[2025-05-01 16:21:19.535] [Debug] [Template Engine] => [Execute]: Execute started
Warning: use of 'dotnet new --install' is deprecated. Use 'dotnet new install' instead.
For more information, run:
   dotnet new install -h


[2025-05-01 16:21:19.539] [Debug] [Microsoft.TemplateEngine.Edge.TemplateConstraintManager] => [Execute]: Found 5 constraints factories, initializing.
[2025-05-01 16:21:19.540] [Debug] [MSBuildEvaluator] => [Execute]: Output directory is: /usr/local/Cellar/azure-functions-core-tools@4/4.0.7030/templates/net-isolated.
[2025-05-01 16:21:19.540] [Debug] [MSBuildEvaluator] => [Execute]: Project full path is: <null>.
[2025-05-01 16:21:19.542] [Debug] [MSBuildEvaluator] => [Execute]: Found project files: .
[2025-05-01 16:21:19.542] [Debug] [MSBuildEvaluator] => [Execute]: No project found.
The following template packages will be installed:
   /usr/local/Cellar/azure-functions-core-tools::4/4.0.7030/templates/net-isolated/projectTemplates.4.0.5051.nupkg


[2025-05-01 16:21:19.601] [Debug] [Microsoft.TemplateEngine.Edge.Installers.NuGet.NuGetInstaller] => [Execute]: /usr/local/Cellar/azure-functions-core-tools is not a local NuGet package.
[2025-05-01 16:21:19.602] [Debug] [Microsoft.TemplateEngine.Edge.Installers.NuGet.NuGetInstaller] => [Execute]: /usr/local/Cellar/azure-functions-core-tools is not a valid NuGet package ID.
[2025-05-01 16:21:19.602] [Debug] [Microsoft.TemplateEngine.Edge.Installers.NuGet.NuGetInstaller] => [Execute]: 4/4.0.7030/templates/net-isolated/projectTemplates.4.0.5051.nupkg is not a valid NuGet package version.
/usr/local/Cellar/azure-functions-core-tools::4/4.0.7030/templates/net-isolated/projectTemplates.4.0.5051.nupkg is not supported.


[2025-05-01 16:21:19.628] [Debug] [Template Engine] => [Execute]: Execute finished, took 93 ms
For details on the exit code, refer to https://aka.ms/templating-exit-codes#106

Further technical details

• Include the output of dotnet --info

.NET SDK:
Version:           9.0.202
Commit:            3a53853c30
Workload version:  9.0.200-manifests.21502d11
MSBuild version:   17.13.13+1c2026462


Runtime Environment:
OS Name:     Mac OS X
OS Version:  15.4
OS Platform: Darwin
RID:         osx-arm64
Base Path:   /usr/local/share/dotnet/sdk/9.0.202/


.NET workloads installed:
There are no installed workloads to display.
Configured to use loose manifests when installing new manifests.


Host:
  Version:      9.0.3
  Architecture: arm64
  Commit:       831d23e561


.NET SDKs installed:
  6.0.414 [/usr/local/share/dotnet/sdk]
  7.0.401 [/usr/local/share/dotnet/sdk]
  8.0.100 [/usr/local/share/dotnet/sdk]
  8.0.300 [/usr/local/share/dotnet/sdk]
  9.0.202 [/usr/local/share/dotnet/sdk]


.NET runtimes installed:
  Microsoft.AspNetCore.App 6.0.22 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 7.0.11 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 8.0.0 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 8.0.5 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 9.0.3 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 6.0.22 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 7.0.11 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 8.0.0 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 8.0.5 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 9.0.3 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]


Other architectures found:
  None


Environment variables:
  Not set


global.json file:
  Not found

[Forgind]

This is intended behavior. Per #45422, we added support for package@version syntax for dotnet new install. (We've been working to have a clean/consistent CLI, and this is one part of that.) We probably should've included it in our release notes as a breaking change; my apologies for not doing that.

Is there a reason you need an @ symbol in your path, or did you just notice it?

[mattchenderson]

@Forgind We don't necessarily control the path in question. Here, we're dealing with HomeBrew defaults from a user machine.

I appreciate the desire for consistency and all, but we're left in a position where the Azure Functions end-to-end for .NET is broken on MacOS. Are there any workarounds available in terms of knobs we could turn for the templating engine, etc.?

[baronfel]

@Forgind this is not intended behavior for file-path-based template installations. We should only be doing the package@version parsing for inputs that are packages/versions - for file paths we should just install that package.

For the template engine specifically we need to separately handle this case - this is a bug/regression and is often used by our own teams when testing templates.