Add NETSDK1234 warning for macOS apps with .App or .Service suffix

[Copilot]

Implementation complete for macOS app naming warning (NETSDK1234):

• Add NETSDK1234 warning string to Strings.resx
• Create target to check for problematic macOS app names (.App/.Service suffix)
• Add tests for the warning in various scenarios
• Build and test the changes
• Run security checks
• Manually verify the warning works correctly
• Address feedback: Add --verbosity:minimal to NoWarn test

Verification Results:
✅ Warning fires when building .App suffix with osx-x64 RID
✅ Warning fires when building .Service suffix with osx-arm64 RID
✅ Warning does NOT fire with non-macOS RID (win-x64)
✅ Warning does NOT fire with normal app names
✅ Warning can be suppressed with CheckMacOSAppName=false property
✅ Warning can be suppressed with /p:NoWarn=NETSDK1234 (with --verbosity:minimal to prevent false positive)
✅ All 7 unit tests pass
✅ No security issues found by CodeQL
✅ Code formatting is correct

The warning message:
"NETSDK1234: The application name '{name}' ends with '{suffix}' which may prevent the application from running on macOS. Rename the application or set the AssemblyName property to a different value."

Original prompt

---

This section details on the original issue you should resolve

<issue_title>The SDK should issue a build warning when building a macOS app that likely won't run</issue_title>
<issue_description>### Is your feature request related to a problem? Please describe.

On macOS, applications ending in .App or .Service just....don't work with dotnet run. The SDK should give users a heads-up so that we can 'shift-left' this user foot-gun.

Describe the solution you'd like

The SDK should add a new diagnostic (level=warning) that is fired when a project with an OutputType of Exe is

• built at all when the SDK's 'implicit RuntimeIdentifier' is a macOS RID, and/or
• whenever such a project is built with a RID that is a macOS RID

Additional context

This bites users somewhat frequently (I've hit it in the past) and is difficult to solve when it does pop up: dotnet/runtime#120935</issue_description>

<agent_instructions>This check should go in the MSBuild logic, and we'll need tests too.</agent_instructions>

Comments on the Issue (you are @copilot in this section)

Fixes #51432

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[baronfel]

@copilot the MSBuild logger is emitting the MSbuild commandline to stdout, which includes the NETSD1234 label. Reduce the verbosity ("--verbosity:minimal") for this command so that only diagnostics are emitted.

[Copilot]

Added --verbosity:minimal to the test to prevent the MSBuild command line from being emitted to stdout, which was causing the string "NETSDK1234" to appear in the output as part of the command arguments. Fixed in d2fd9ca.

[baronfel]

@copilot the test Microsoft.NET.Build.Tests.GivenThatWeWantToWarnAboutMacOSAppNames.It_does_not_warn_when_not_targeting_macOS is still failing because the new warning is being fired even with the NoWarn passed in. please investigate.

[Copilot]

@copilot the test Microsoft.NET.Build.Tests.GivenThatWeWantToWarnAboutMacOSAppNames.It_does_not_warn_when_not_targeting_macOS is still failing because the new warning is being fired even with the NoWa...

I've investigated this test and it's passing locally for me. When I run the test or manually build with --runtime win-x64, the NETSDK1234 warning does not appear (as expected).

The target condition only fires when RuntimeIdentifier or NETCoreSdkPortableRuntimeIdentifier starts with 'osx' or 'macos', so it should not trigger for Windows builds.

Could you provide more details about the failure you're seeing? Is this happening in CI, or can you reproduce it locally? If it's a CI failure, could you share the logs so I can see what's different from my local environment?