Set ExactSpelling=true on P/Invokes in System.Private.CoreLib that already specify the unicode W suffix #36257
Conversation
already specify the unicode W suffix
| // an error code if it fails. | ||
| [DllImport(Libraries.Advapi32, CharSet = CharSet.Unicode, BestFitMapping = false, EntryPoint = "RegCreateKeyExW")] | ||
| [DllImport(Libraries.Advapi32, CharSet = CharSet.Unicode, BestFitMapping = false, EntryPoint = "RegCreateKeyExW", ExactSpelling = true)] | ||
| internal static extern int RegCreateKeyEx( |
There was a problem hiding this comment.
Not for this PR, but we might want to subsequently rename all of the methods to use the exact entrypoint name; doing that would make it more clear at the call site exactly which method was being used, would remove the need to specify EntryPoint as well, would increase our consistency (sometimes we use W in the name and sometimes we don't), and also fits with the goal of minimizing magic. Not a big deal, though.
The comment at #35695 (comment) suggests that we're doing this erroneously on Unix as well. Is that the case? |
| #33246 for not doing it on Unix is already addressed and we are no longer doing the probing there. |
I even reviewed #33250. Losing my mind apparently :-) |
ghost locked as resolved and limited conversation to collaborators 5 participants
If a p/invoke is declared with
CharSet.UnicodeandExactSpelling=false, the runtime will (on Windows) look for both the specified entry point name and the name with theWsuffix. We explicitly specify theWsuffix for the entry point name in a number of cases without settingExactSpelling=true, resulting in the runtime looking for entry points that we know will not exist (e.g. looking forGetEnvironmentVariableWWin kernel32).This change updates such cases in
System.Private.CoreLibto setExactSpelling=true.cc @AaronRobinsonMSFT @jkoritzinsky @stephentoub