Emit helpful error when a NativeMethods.txt request with no match contains unexpected non-ANSI characters

[AliveDevil]

Actual behavior

Adding

SHGetKnownFolderItem

NativeMethods.txt fails with

warning PInvoke001: Method, type or constant "SHGet­Known­Folder­Item" not found.

Using Shell32.* does generate SHGetKnownFolderItem correctly.

Expected behavior

SHGetKnownFolderItem is generated the same as it is with Shell32.*.

Repro steps

1. NativeMethods.txt content:

SHGetKnownFolderItem

Context

• CsWin32 version: 0.1.560-beta
• Target Framework: net5.0-windows10.0.17763.0

[AArnott]

It works for me.

There is something wrong with your e.
Copy and paste SHGet­Known­Folder­Item from this very sentence and search for it with your browser. On mine it only match 3 times in your issue description.
Now copy and paste SHGetKnownFolderItem from this very sentence and search for it with your browser. On mine it matches 5 times in your issue description.

Visually I can't see what's wrong. But I suggest you re-type the method name yourself into your NativeMethods.txt file (or copy-paste it from here: SHGetKnownFolderItem) and I expect it will work for you.

You may have some weird unicode character for or around your e.

[AliveDevil]

It's not around the "e", its basically SH <Soft Hyphen> Get <Soft Hyphen> Known <Soft Hyphen> Folder <Soft Hyphen> Item. (0xAD, ASCII). I'm unsure where I got that string from, though. I just tried Microsoft-docs and it works with copy&paste there without issue. Strange. Yeah, Chromium is the culprit for even including the soft hyphen in the first place: https://bugs.chromium.org/p/chromium/issues/detail?id=767950

Eventually some better output for hidden unicode characters scrambling the input?

[AArnott]

Sure. I recently learned that function names are limited to the ANSI charset. Or at least, GetProcAddress never won a W variant. Emitting a guiding error about unexpected characters being there sounds like a good idea, as I doubt you're the only one who will hit this.