Convert To 'LibraryImport' with 'W' suffix creates invalid code

[Symbai]

I have the following existing code:

[DllImport(Lib.Kernel32, SetLastError = true, CharSet = CharSet.Unicode)]
		[return: MarshalAs(UnmanagedType.Bool)]
		public static extern bool Process32FirstW(IntPtr hSnapshot, ref PROCESSENTRY32 lppe);

VS suggests me to convert it to LibraryImport, there is also an option to use W suffix:

I've chosen that and it created:

		[LibraryImport(Lib.Kernel32, EntryPoint = "Process32FirstWW", SetLastError = true)]
		[return: MarshalAs(UnmanagedType.Bool)]
		public static partial bool Process32FirstW(IntPtr hSnapshot, ref PROCESSENTRY32 lppe);

Obviously there is no such Process32FirstWW entrypoint. I don't know at which logic VS suggests sometimes only A prefix, sometimes only W prefix and sometimes no prefix at all. But seeing that there must be a logic somehow, the logic leads to invalid code at this point. For some people its obvious, for other people it might not. However I think that IF VS suggests to use W suffix which seems to be based on some logic, it must be correct, or it should just not show any suffix option at all (which VS is doing for some other pinvokes).

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

Issue Details

---

I have the following existing code:

[DllImport(Lib.Kernel32, SetLastError = true, CharSet = CharSet.Unicode)]
		[return: MarshalAs(UnmanagedType.Bool)]
		public static extern bool Process32FirstW(IntPtr hSnapshot, ref PROCESSENTRY32 lppe);

VS suggests me to convert it to LibraryImport, there is also an option to use W suffix:

I've chosen that and it created:

		[LibraryImport(Lib.Kernel32, EntryPoint = "Process32FirstWW", SetLastError = true)]
		[return: MarshalAs(UnmanagedType.Bool)]
		public static partial bool Process32FirstW(IntPtr hSnapshot, ref PROCESSENTRY32 lppe);

Obviously there is no such Process32FirstWW entrypoint. I don't know at which logic VS suggests sometimes only A prefix, sometimes only W prefix and sometimes no prefix at all. But seeing that there must be a logic somehow, the logic leads to invalid code at this point. For some people its obvious, for other people it might not. However I think that IF VS suggests to use W suffix which seems to be based on some logic, it must be correct, or it should just not show any suffix option at all (which VS is doing for some other pinvokes).

Author:	Symbai
Assignees:	-
Labels:	area-System.Runtime.InteropServices, untriaged
Milestone:	-

[AaronRobinsonMSFT]

However I think that IF VS suggests to use W suffix which seems to be based on some logic, it must be correct, or it should just not show any suffix option at all (which VS is doing for some other pinvokes).

That is fair. This seems like we assumed most people didn't use the prefix but when you do it causes issues. The confusion here is likely the matrix of how we look up exports and the values of CharSet and ExactSpelling.

[AaronRobinsonMSFT]

@jtschuster Any chance you can look into this?

[jkoritzinsky]

We suggest a suffix based on the provided CharSet if the user did not specify ExactSpelling.

We'd have to pull in something like the Win32Metadata project or some other source of truth if we only want to suggest the suffix when it exists for Win32 APIs (and assume that no non-Win32 use the suffix).

[AaronRobinsonMSFT]

We'd have to pull in something like the Win32Metadata project or some other source of truth if we only want to suggest the suffix when it exists for Win32 APIs (and assume that no non-Win32 use the suffix).

I read this slightly differently. We could instead check if a W or an A already exists and act accordingly. Presumably there isn't any API with a WW or an AA suffix so we could avoid doing that. It is also possible there isn't much value in handle this niche case.

[jkoritzinsky]

I think detecting an existing suffix makes sense.