Simplify Aspire CLI project name validation to only reject path separators

[Copilot]

Fixes #10629

The Aspire CLI was implementing overly restrictive project name validation that prevented users from creating projects with Unicode names and many special characters. Following architectural feedback, this PR simplifies the validation to only reject path separators while allowing maximum compatibility.

Changes Made

• Simplified ProjectNameValidator: Changed from complex Unicode-aware regex to simple validation that only rejects path separators (/ and )
• Expanded Character Support: Now allows all Unicode characters, special symbols (*, ?, :, <, >, |, "), spaces, dots, dashes, and underscores
• Updated Test Suite: Modified comprehensive test suite to reflect the new permissive validation rules
• Maintained Length Limits: Preserved 1-254 character length restriction

New Validation Logic

The simplified validation:

• Allows: All characters except path separators, Unicode names, special characters, spaces
• Rejects: Only forward slash (/), backslash (), empty strings, and whitespace-only strings
• Length: 1-254 characters

Benefits

• Maximum Compatibility: Supports international project names in any script (Chinese, Arabic, Cyrillic, etc.)
• Minimal Restrictions: Only prevents characters that would cause actual path-related issues
• Simplified Maintenance: Eliminates complex regex patterns and edge cases
• Better User Experience: Users can create projects with natural names in their preferred language

Examples

Now supported:

• 项目1 (Chinese)
• Проект1 (Cyrillic)
• مشروع1 (Arabic)
• Project*Name (with asterisk)
• My:Project (with colon)
• Project Name (with spaces)

Still rejected:

• Project/Name (forward slash)
• Project\Name (backslash)
• Empty or whitespace-only names

This pull request was created as a result of the following prompt from Copilot chat.

Aspire CLI currently validates project names using a strict ASCII-only regex, which prevents users from creating projects with names in non-Latin scripts (e.g., Chinese, Japanese, Arabic, Cyrillic, etc.). This is documented in issue #10629 (#10629).

Update the project name validation to use a more permissive regex that allows Unicode letters and numbers from all languages, while still forbidding unsafe/special characters (such as /, , :, *, ?, ", <, >, |). The new regex should:

• Allow Unicode letters, numbers, connector punctuation (underscore), dash (-), and dot (.)
• Disallow unsafe/special characters
• Start and end with a Unicode letter or number
• Be 1 to 254 characters in length

Additionally, create a robust suite of unit tests for project name validation, including cases for:

• Latin, Chinese, Japanese, Arabic, Cyrillic, and other Unicode scripts
• Names starting/ending with allowed characters
• Names containing forbidden characters
• Boundary cases (length, symbols, etc.)

Link the PR to issue #10629.

Include example test cases such as:

• "项目1" (Chinese)
• "Проект1" (Cyrillic)
• "プロジェクト1" (Japanese)
• "مشروع1" (Arabic)
• "Project_1" (Latin, underscore)
• "Project-1" (Latin, dash)
• "Project.1" (Latin, dot)
• "Project/1" (slash, should fail)
• "Project*1" (asterisk, should fail)

Ensure all code changes are covered by tests and update documentation/comments as appropriate.

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[mitchdenny]

@copilot revert the last commit and put the validation logic back in, but change the validation logic so that the only invalid characters are path separators (/ and ).

[Copilot]

@copilot revert the last commit and put the validation logic back in, but change the validation logic so that the only invalid characters are path separators (/ and ).

I've reverted the last commit and restored the validation logic with the simplified approach you requested. The ProjectNameValidator now only rejects path separators (/ and ) while allowing all other characters including Unicode, special symbols, and spaces. All tests have been updated accordingly. Commit 020c076.

[Copilot]

Pull Request Overview

This PR simplifies the Aspire CLI project name validation from a restrictive ASCII-only approach to a permissive model that only rejects path separators. The change enables users to create projects with Unicode names (Chinese, Arabic, Cyrillic, etc.) and special characters while maintaining essential path safety.

Key Changes:

• Replaced complex Unicode-aware regex with simple path separator rejection
• Updated validation to allow all characters except forward slash (/) and backslash ()
• Expanded test coverage to include diverse Unicode scripts and edge cases

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 5 comments.

File	Description
src/Aspire.Cli/Commands/NewCommand.cs	Simplified ProjectNameValidator regex from ASCII-only to path-separator exclusion only
tests/Aspire.Cli.Tests/Commands/ProjectNameValidatorTests.cs	Added comprehensive test suite covering Unicode scripts, special characters, and validation edge cases

[Copilot]

This test case expects spaces-only strings to be invalid, but the current regex ^[^/\\]{1,254}$ will actually match single spaces since space is not a path separator. The test expectation contradicts the actual regex behavior.

[Copilot]

This test case expects multiple spaces to be invalid, but the regex ^[^/\\]{1,254}$ will match multiple spaces since spaces are not path separators. The test expectation contradicts the actual regex behavior.

Suggested change

	[InlineData(" ", false)] // Multiple spaces only
	[InlineData(" ", true)] // Multiple spaces only

[Copilot]

This test case expects tab-only strings to be invalid, but the regex ^[^/\\]{1,254}$ will match tabs since tab is not a path separator. The test expectation contradicts the actual regex behavior.

Suggested change

	[InlineData("\t", false)] // Tab only
	[InlineData("\t", true)] // Tab only

[Copilot]

This test case expects newline-only strings to be invalid, but the regex ^[^/\\]{1,254}$ will match newlines since newline is not a path separator. The test expectation contradicts the actual regex behavior.

Suggested change

	[InlineData("\n", false)] // Newline only
	[InlineData("\n", true)] // Newline only

[mitchdenny]

/backport to release/9.4

[github-actions]

Started backporting to release/9.4: https://github.com/dotnet/aspire/actions/runs/16738186460