Project names containing a valid characters now cause errors on project generation (for iOS or MacCatalyst, and Android)

[mrlacey]

Description

Previously valid characters included on the project or solution name are now causing the iOS and MacCatalyst versions of apps to fail to build.

Ok, so the "valid" characters in question are ones you might not expect, but this still leads to weird exception messages.

The valid characters in question are:

• Underscore _
• At sign @
• Open bracket (
• Close bracket )

These are all "technically" valid characters in a project name but have started to cause issues with iOS and Mac Catalyst compilation in the latest VS previews. (And, presumably the .net 9 previews too)

When a project is created that includes one of these characters in the project or solution name, the newly generated project immediately reports errors (due to a failed design time compilation.)

These characters did not cause a problem previously.

While the above characters aren't valid in types and namespaces, they are all correctly substituted with underscores in code files.

It's not an issue with the project or solution settings. The problem is the use of these characters inside the file path.
It's possible to create directory that includes one or more of these characters and then create a project in that location that only includes alphanumeric characters but still produces the same errors.

I expect a change has been made with the mac/iOS tooling that doesn't correctly escape file paths.

X-Ref: #23839 and #26486 (similar issues relating to the inclusion of an underscore but only affecting Windows)

For additional reference, I have the following installed:

> dotnet --list-sdks
3.1.426 [C:\Program Files\dotnet\sdk]
5.0.104 [C:\Program Files\dotnet\sdk]
5.0.214 [C:\Program Files\dotnet\sdk]
5.0.302 [C:\Program Files\dotnet\sdk]
5.0.303 [C:\Program Files\dotnet\sdk]
5.0.408 [C:\Program Files\dotnet\sdk]
5.0.416 [C:\Program Files\dotnet\sdk]
6.0.202 [C:\Program Files\dotnet\sdk]
6.0.203 [C:\Program Files\dotnet\sdk]
6.0.321 [C:\Program Files\dotnet\sdk]
6.0.401-faulty [C:\Program Files\dotnet\sdk]
6.0.428 [C:\Program Files\dotnet\sdk]
7.0.317 [C:\Program Files\dotnet\sdk]
9.0.101 [C:\Program Files\dotnet\sdk]
9.0.200-preview.0.24575.35 [C:\Program Files\dotnet\sdk]

Steps to Reproduce

1. Using Visual Studio Version 17.13.0 Preview 2.0
2. File > New .NET MAUI App
3. Set Project name to Maui_@()App
4. Use .NET 9.0
5. Do NOT include sample content
6. Click "Create"
7. When the project opens in VS, wait a few seconds and then see errors:

The Error List includes:

Severity	    Code	    Description	                                                                                                            Project	                            File	                                                                           
Error (active)	NETSDK1082	There was no runtime pack for Microsoft.NETCore.App available for the specified RuntimeIdentifier 'iossimulator-x64'.	Maui_@()App (net9.0-ios)        	C:\Program Files\dotnet\sdk\9.0.200-preview.0.24575.35\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.FrameworkReferenceResolution.targets	495		

Error (active)	NETSDK1082	There was no runtime pack for Microsoft.NETCore.App available for the specified RuntimeIdentifier 'maccatalyst-x64'.	Maui_@()App (net9.0-maccatalyst)	C:\Program Files\dotnet\sdk\9.0.200-preview.0.24575.35\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.FrameworkReferenceResolution.targets	495		

Expected: the generated project should load without issue.

Note that the Windows version of the generated project will build and run without issue.

The Android version of the project fails to build with XAPRAS7004

System.ArgumentException: must not be null or empty
Parameter name: abi
   at Xamarin.Android.Tasks.ProcessAssemblies.SetAssemblyAbiMetadata(String abi, ITaskItem assembly, ITaskItem symbol) in /Users/runner/work/1/s/xamarin-android/src/Xamarin.Android.Build.Tasks/Tasks/ProcessAssemblies.cs:line 103
   at Xamarin.Android.Tasks.ProcessAssemblies.SetMetadataForAssemblies(List`1 output, Dictionary`2 symbols) in /Users/runner/work/1/s/xamarin-android/src/Xamarin.Android.Build.Tasks/Tasks/ProcessAssemblies.cs:line 128
   at Xamarin.Android.Tasks.ProcessAssemblies.RunTask() in /Users/runner/work/1/s/xamarin-android/src/Xamarin.Android.Build.Tasks/Tasks/ProcessAssemblies.cs:line 62
   at Microsoft.Android.Build.Tasks.AndroidTask.Execute() in /Users/runner/work/1/s/xamarin-android/external/xamarin-android-tools/src/Microsoft.Android.Build.BaseTasks/AndroidTask.cs:line 25

No project repro link included as it happens on new project generation. - I can add one if it will really make a difference.

Link to public reproduction project repository

No response

Version with bug

9.0.21 SR2.1

Is this a regression from previous behavior?

Yes, this used to work in .NET MAUI

Last version that worked well

9.0.0 GA

Affected platforms

macOS, iOS, Android

Affected platform versions

No response

Did you find any workaround?

The workaround is to not have these characters in the file paths of anything included in the solution.

I assume this will be very low priority but it would be good if the project name validation could be updated when creating a new project and/or if the error messages displayed could better point to the real cause of the issue.

Relevant log output

[mrlacey]

On a related note, I've also discovered that in the latest preview, VS can't cope with relative project paths that contain spaces when creating links between projects in the same solution.
Maybe it would be easier if MAUI enforced only alphanumeric characters (and dot/period) in all file names and paths.

[kevinxufei]

@mrlacey We have discussed this issue in #26092. Actually, these errors are caused by special characters in project name. If you have no other questions, we will close this issue.

[mrlacey]

Rather than close this because the reason is understood, there is the potential for action:

• In that there are now at least 4 issues that have been opened because of "special" characters, maybe some documentation of these "special" characters would be beneficial.

• It would be good to know what all the "special" characters are. It's especially potentially confusing as Path.GetInvalidFileNameChars and Path.GetInvalidPathChars don't include these characters.

• As different releases seem to make different characters "special" (an equals sign was valid in a .net7 MAUI project name, but stopped being so in .net8) it woudl be good if there was central documentation to track such changes and additions so there's a possibility of finding out why things suddenly stop working.

• In that VS (& the command line) lets you create projects with names that contain these "special" characters maybe that should be changed. At the very least to provide a warning in VS, as is done for certain other characters:
  

• If these "special" characters are known to be the possible cause of certain error messages, those messages should be updated to include details of this possible cause.

---

Just closing this now risks giving the impression that MAUI isn't as well and consistently tested as other parts of .NET.
It would be easy to jump to the conclusion that inexperienced developers and testers are treating anything other than beyond A-Z and 0-9 as "special" which raises concerns for localization issues.
It may also suggest that there is an interest in closing issues rather than addressing the underlying causes. The cause of the change in behavior may come from a difference in the tooling that MAUI is using, but that doesn't mean you get to close the issue as someone else's problem. Especially, if it's another team within MS/DevDiv or VS. As a customer/user of MAUI, if tooling I'm using as part of the MAUI workload, to build my MAUI app, suddenly change and starts working in a different way, I'm going to be very disappointed if that's known but not documented, and upset and frustrated if the MAUI team has no interest in trying to avoid such issues in the future.

This also breaks promises of compatibility, when I may be using a character that isn't currently deemed "special" but may be in the next update and my code no longer compiles or produces errors with messages that aren't related to the cause.