#64: String projection

[saul]

This fixes #64.

• [In] strings are now projected to [MarshalAs(UnmanagedType.LPxStr)] string param
• [Out] strings are now projected to [MarshalAs(UnmanagedType.LPxStr)] StringBuilder param

For example, CredUIPromptForCredentials is now projected to:

internal static extern unsafe uint CredUIPromptForCredentials(
    [In, Optional] CREDUI_INFOW*pUiInfo,
    [MarshalAs(UnmanagedType.LPWStr)] string pszTargetName,
    SecHandle*pContext,
    uint dwAuthError,
    [MarshalAs(UnmanagedType.LPWStr)] System.Text.StringBuilder pszUserName,
    uint ulUserNameBufferSize,
    [MarshalAs(UnmanagedType.LPWStr)] System.Text.StringBuilder pszPassword,
    uint ulPasswordBufferSize,
    [In, Out, Optional] int *save,
    uint dwFlags);

If the SizeParamIndex annotation is set on the parameter, then the overloaded method passes StringBuilder.Capacity as the buffer size.

I also did some cleanup to make it a bit easier to comprehend. I abstracted the two places where the NativeTypeInfoAttribute is read into a new method and represented it with a new NativeTypeInfo struct.

[jnm2]

Could you make it char* instead of StringBuilder? I never want to use StringBuilder in p/invoke signatures, and https://docs.microsoft.com/en-us/dotnet/standard/native-interop/best-practices#string-parameters also recommends against it.

To clarify: I'm hoping for the same overload to be able to have parameters string somethingIn, char* somethingOut.

Or string somethingIn, Span<char> somethingOut.

[saul]

That's a really informative page - thanks for linking.

Out of interest why char* instead of char[], as the page suggests? I imagine the latter is a bit more ergonomic.

[jnm2]

I agree, string somethingIn, char[] somethingOut seems more ergonomic than char*.

If these types are available, I think this is more ergonomic still, because you can pass more than just char[] to the second parameter and more than just string (including char[]!) to the first parameter:
ReadOnlySpan<char> somethingIn, Span<char> somethingOut

[AArnott]

The generated extern method should indeed be char*. This should then automatically lead to generation of an overload that takes a Span<char> or ReadOnlySpan<char> depending on the data direction.

char[] is implicitly castable to Span<char>, so using a span allows for many other scenarios, allowing reduced GC pressure and less memory copying.

[AArnott]

BTW: the code cleanup that you mixed into this may cause the PR to take longer to merge. Ideally functional changes and cleanups would be in separate PRs for easier code reviews.
But I do appreciate you contributing!

[AArnott]

Some other significant string changes are coming in a metadata update, so I'm going to take those and fix the bug in a more focused PR. @saul, I am interested in refactoring if it improves maintainability, but we should discuss in a github issue before you go to the trouble.

Thank you for your submission.