[API Proposal]: Marshal.GetPInvokeErrorMessage() overload for localization

[AaronRobinsonMSFT]

Background and motivation

Follow-up on #67872 for adding a localization overload.

The utility of this function is often for developer to log. However, the localization is dependent on the user's machine configuration, not the developers. It would be helpful for people for their logging utilities to be able to specify that locale and not rely on the user's machine.

User related conversation #40427 (comment)

API Proposal

namespace System.Runtime.InteropServices;

public partial class Marshal
{
    // Existing
    // public static int GetLastPInvokeError();
    // public static string GetLastPInvokeErrorMessage();
    // public static string GetPInvokeErrorMessage(int error);
+    public static string GetPInvokeErrorMessage(int error, CultureInfo cultureInfo);
}

There doesn't seem to be a strong need for an overload for public static string GetLastPInvokeErrorMessage(CultureInfo cultureInfo);, but that is an option.

API Usage

string presentToUser = Marshal.GetPInvokeErrorMessage(error, CultureInfo.CurrentUICulture);
string logForDev = Marshal.GetPInvokeErrorMessage(error, CultureInfo.CreateSpecificCulture("en-us"));

Alternative Designs

No response

Risks

No response

[ghost]

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

Issue Details

---

Background and motivation

Follow-up on #67872 for adding a localization overload.

User related conversation #40427 (comment)

The utility of this function is often for developer to log. However, the localization is dependent on the user's machine configuration, not the developers. It would be helpful for people for their logging utilities to be able to specify that locale and not rely on the user's machine.

API Proposal

namespace System.Runtime.InteropServices;

public partial class Marshal
{
    // Existing
    // public static int GetLastPInvokeError();
    // public static string GetLastPInvokeErrorMessage();
    // public static string GetPInvokeErrorMessage(int error);
+    public static string GetPInvokeErrorMessage(int error, CultureInfo cultureInfo);
}

API Usage

string presentToUser = Marshal.GetPInvokeErrorMessage(error, CultureInfo.CurrentUICulture);
string logForDev = Marshal.GetPInvokeErrorMessage(error, CultureInfo.CreateSpecificCulture("en-us"));

Alternative Designs

No response

Risks

No response

Author:	AaronRobinsonMSFT
Assignees:	-
Labels:	api-suggestion, area-System.Runtime.InteropServices
Milestone:	8.0.0

[stephentoub]

What does this do on Unix?

What does this do if the relevant resources aren't available?

Is CultureInfo the right thing to accept?

[AaronRobinsonMSFT]

What does this do on Unix?
What does this do if the relevant resources aren't available?

It would be dependent on if the platform supports localized error messages. If the platform doesn't or if resources aren't available, the behavior would be identical to the non-localized API.

Is CultureInfo the right thing to accept?

I defer to @tarekgh and @ericstj for that.

[jkotas]

It would be dependent on if the platform supports localized error messages.

This would work only on Windows and only if the machine has multiple language packs installed that I believe is relatively rare.

[jkotas]

It may make more sense to change the current GetPInvokeErrorMessage(int error) API to respect CultureInfo.CurrentUICulture if possible, to match the behavior of regular exception messages.

[tarekgh]

The original issue triggered this proposal is how to get the English message when running on Windows localized version. This API can help in that scenario, but I agree with Jan it is limited to such specific scenario. May be better to think in other way achieving the same without such API?

[jkotas]

The original issue triggered this proposal is how to get the English message when running on Windows localized version.

Are English resources guaranteed to be available on Windows localized versions? IIRC, I do not think they are out of the box.

[tarekgh]

I am not fully sure, but English resources should always exist. We can validate that.

[tarekgh]

I confirmed with Windows team that it is not guaranteed the English resources will exist all the time.

[tarekgh]

I guess after this discovery I suggest closing this proposal. Thanks @AaronRobinsonMSFT for being proactive and trying to help solve the issue.

[ericstj]

No need to reopen, but I found this could be helpful if the language pack is installed. Not sure how many end users will be running with multiple languages. Here's a gist of what I did to help get Win32Exceptions in other languages. It's a shameless copy of this API https://gist.github.com/ericstj/c72b90b0c12f86b7918850ee276fac3b