Workaround for .NET Native toolchain issue #378
Conversation
The issue is that SupportedAPIs-x86.xml and SupportedAPIs-x64.xml file, as found at C:\Program Files (x86)\Windows Kits\10\App Certification Kit\SupportedAPIs-x??.xml claim that some encoding-neutral methods are actually exported by Windows. This leads .NET Native to generate bindings against them when they don't exist. Until the Windows SDK is fixed, we workaround it by specifying the W unicode suffix for the relevant methods directly. Specifically changed are these methods: * FirstFirstFileEx * CreateMutex * FormatMessage
| @@ -141,7 +141,7 @@ public static partial class Kernel32 | |||
| /// If the function succeeds, the return value is the number of TCHARs stored in the output buffer, excluding the terminating null character. | |||
| /// If the function fails, the return value is zero. To get extended error information, call <see cref="GetLastError"/>. | |||
| /// </returns> | |||
| [DllImport(api_ms_win_core_localization_l1_2_0, CharSet = CharSet.Unicode, SetLastError = true)] | |||
| [DllImport(api_ms_win_core_localization_l1_2_0, CharSet = CharSet.Unicode, EntryPoint = "FormatMessageW", ExactSpelling = true, SetLastError = true)] | |||
There was a problem hiding this comment.
You dont need ExactSpelling = true
There was a problem hiding this comment.
Thanks for reviewing. It doesn't seem to do any harm either, so I'm going to leave it as a way of expressing that I add the W suffix so the system doesn't need to try.
I hope this is just a temporary workaround anyway till the Windows SDK is fixed.
There was a problem hiding this comment.
Yes , we have a thread going with windows and there are more suffix free APIs that they added with no exports. Plan is to fix it by 4/6
There was a problem hiding this comment.
=> temporary workaround anyway till the Windows SDK is fixed.
Forgot to mention that , using explicitly W or A is a good practice and i believe the core recommendation is to use "W" always. So even after windows fix it , you should consider keeping this change.
The issue is that SupportedAPIs-x86.xml and SupportedAPIs-x64.xml file, as found at
C:\Program Files (x86)\Windows Kits\10\App Certification Kit\SupportedAPIs-x??.xml
claim that some encoding-neutral methods are actually exported by Windows.
This leads .NET Native to generate bindings against them when they don't exist.
Until the Windows SDK is fixed, we workaround it by specifying the W unicode
suffix for the relevant methods directly.
Specifically changed are these methods:
Closes #377 by workaround