Extend ERROR_NO_ASSOCIATION with descriptive error messages

[Copilot]

Addresses review feedback from @jkotas on #132219. The two throw new Win32Exception(Interop.Errors.ERROR_NO_ASSOCIATION) calls in SafeProcessHandle.Unix.cs produced opaque Win32 error codes that are meaningless on Unix. Replaced with clear, actionable messages.

Changes:

• Added UseShellExecuteVerbNotSupported resource string for the unsupported verb case (includes the verb name)
• Added UseShellExecuteNoOpenProgram resource string for the missing file-opener case
• Replaced both throw sites with new Win32Exception(SR....) using these strings

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).
13 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[adamsitnik]

@copilot address my feedback and make sure [this[(https://github.com/dotnet/runtime/blob/d00a0a24912957046ed2443adc0af7bbfb4c43bc/src/libraries/System.Diagnostics.Process/tests/ProcessTests.Unix.cs#L82-L94) test is going to pass

[Copilot]

Pull request overview

Updates System.Diagnostics.Process Unix UseShellExecute failure paths to use localized, descriptive resource strings instead of relying on ERROR_NO_ASSOCIATION alone.

Changes:

• Added two new resource strings for Unix UseShellExecute failure scenarios (unsupported verb; no opener program found).
• Updated SafeProcessHandle.Unix.cs to throw Win32Exception with these messages at the two existing failure points.

Reviewed changes

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

File	Description
src/libraries/System.Diagnostics.Process/src/Resources/Strings.resx	Adds new localized strings for Unix UseShellExecute error messages.
src/libraries/System.Diagnostics.Process/src/Microsoft/Win32/SafeHandles/SafeProcessHandle.Unix.cs	Switches thrown exceptions to use the new resource strings for clearer diagnostics.

Suppressed comments (1)

src/libraries/System.Diagnostics.Process/src/Microsoft/Win32/SafeHandles/SafeProcessHandle.Unix.cs:408

• This message-only Win32Exception changes NativeErrorCode to 0. Process.Start(UseShellExecute=true) on Unix previously threw with ERROR_NO_ASSOCIATION and has test coverage asserting that error code (ProcessTests.Unix.cs:92). Preserve the error code and just improve the message.

            filename = Process.GetPathToOpenFile() ?? throw new Win32Exception(SR.UseShellExecuteNoOpenProgram);

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-diagnostics-process
See info in area-owners.md if you want to be subscribed.

[Copilot]

@copilot address my feedback and make sure [this[(https://github.com/dotnet/runtime/blob/d00a0a24912957046ed2443adc0af7bbfb4c43bc/src/libraries/System.Diagnostics.Process/tests/ProcessTests.Unix.cs#L8...

Fixed in 9f8b1e0 (short hash from latest push): both throw sites now use Win32Exception(Interop.Errors.ERROR_NO_ASSOCIATION, message) so NativeErrorCode is preserved, which keeps ProcessStart_UseShellExecute_OnUnix_ThrowsWhenNoOpenerOnPath passing.

@copilot address my feedback and make sure [this[(https://github.com/dotnet/runtime/blob/d00a0a24912957046ed2443adc0af7bbfb4c43bc/src/libraries/System.Diagnostics.Process/tests/ProcessTests.Unix.cs#L8...

Correction: the fix is in 329f035, not the hash I mentioned above.

[adamsitnik]

LGTM assuming the CI is going to pass.

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).
13 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[Copilot]

Pull request overview

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

Suppressed comments (1)

src/libraries/System.Diagnostics.Process/src/Resources/Strings.resx:398

• UseShellExecuteNoOpenProgram is thrown when Process.GetPathToOpenFile() returns null (i.e., no opener executable like xdg-open/open could be found). The current text reads like a file-type association problem, which is misleading on Unix and not very actionable. Consider wording it explicitly as “no shell opener program found/installed” and (optionally) give examples.

  <data name="UseShellExecuteNoOpenProgram" xml:space="preserve">
    <value>No application is associated with the specified file or URL for UseShellExecute on this platform.</value>
  </data>

[adamsitnik]

UseShellExecuteNoOpenProgram is thrown when Process.GetPathToOpenFile() returns null (i.e., no opener executable like xdg-open/open could be found). The current text reads like a file-type association problem, which is misleading on Unix and not very actionable. Consider wording it explicitly as “no shell opener program found/installed” and (optionally) give examples.

@copilot this is true, Please address this feedback and clarify the error message

[Copilot]

UseShellExecuteNoOpenProgram is thrown when Process.GetPathToOpenFile() returns null (i.e., no opener executable like xdg-open/open could be found). The current text reads like a file-type associati...

Addressed in 28270ca: updated UseShellExecuteNoOpenProgram to explicitly state that no shell opener program was found and to suggest common opener programs (xdg-open / open).

[Copilot]

Pull request overview

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

Suppressed comments (2)

src/libraries/System.Diagnostics.Process/src/Resources/Strings.resx:394

• The message uses double quotes around "open" while the rest of the resources in this file (and this same message) use single quotes for quoted tokens. Consider switching to single quotes (and optionally noting case-insensitivity) for consistency and easier localization.

    <value>The verb '{0}' is not supported for UseShellExecute on this platform. Only the default verb (an empty string or "open") is supported.</value>

src/libraries/System.Diagnostics.Process/src/Resources/Strings.resx:397

• This message labels 'open' as a macOS opener, but this repo also uses '/usr/local/bin/open' for FreeBSD/OpenBSD (see Process.FreeBSD.cs / Process.OpenBSD.cs). Consider broadening the platform note to avoid confusing users on BSD.

    <value>No shell opener program was found for UseShellExecute on this platform. Install one such as 'xdg-open' (Linux) or 'open' (macOS).</value>

[Copilot]

Pull request overview

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