8000 Templating workflows broken for paths with special characters on MacOS since SDK 9.0.200 · Issue #48794 · dotnet/sdk · GitHub
[go: up one dir, main page]
Skip to content

Templating workflows broken for p 8000 aths with special characters on MacOS since SDK 9.0.200 #48794

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
mattchenderson opened this issue May 1, 2025 · 3 comments · Fixed by #48874
Closed

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

mattchenderson opened this issue May 1, 2025 · 3 comments · Fixed by #48874
Assignees
@Forgind

Comments

@mattchenderson
Copy link

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
@dotnet-policy-service dotnet-policy-service bot added the untriaged Request triage from a team member label May 1, 2025
@Forgind
Copy link
Contributor
Forgind commented May 6, 2025

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?

@Forgind Forgind closed this as not planned Won't fix, can't repro, duplicate, stale May 6, 2025
@dotnet-policy-service dotnet-policy-service bot removed the untriaged Request triage from a team member label May 6, 2025
@mattchenderson
Copy link
Author

@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
Copy link
Member
baronfel commented May 8, 2025

@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.

@baronfel baronfel reopened this May 8, 2025
@dotnet-policy-service dotnet-policy-service bot added the untriaged Request triage from a team member label May 8, 2025
@Forgind Forgind mentioned this issue May 8, 2025
Merged
MiYanni added a commit that referenced this issue May 19, 2025
@MiYanni
Skip splitting for paths Fixes #48794 (#48874)
02ab00a
@dotnet-policy-service dotnet-policy-service bot removed the untriaged Request triage from a team member label May 19, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@Forgind Forgind

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Skip splitting for paths Fixes #48794 Forgind/sdk
3 participants
@baronfel @mattchenderson @Forgind
0