Determine the Correct Way to Handle PInvoke DLLImports Across all Platforms #2091
Description
This issue arose out of the initial work to resolve #1705. The issue is that as currently written, PowerShell requires additional API sets for Windows 7 beyond what CoreCLR ships via the runtime.<platform+arch>.Microsoft.NetCore.WIndows.ApiSets package.
Specifically, these API sets cannot be resolved
| PInvokeDllName | API Set | Classic DLL |
|---|---|---|
CreateJobObjectDllName |
api-ms-win-core-job-l2-1-0.dll | kernel32.dll |
GetDCDllName |
ext-ms-win-ntuser-dc-access-ext-l1-1-0.dll | user32.dll |
ReleaseDCDllName |
ext-ms-win-ntuser-dc-access-ext-l1-1-0.dll | user32.dll |
TranslateCharsetInfoDllName |
ext-ms-win-gdi-font-l1-1-1.dll | gdi32.dll |
GetTextMetricsDllName |
ext-ms-win-gdi-font-l1-1-1.dll | gdi32.dll |
GetCharWidth32DllName |
ext-ms-win-gdi-font-l1-1-1.dll | gdi32.dll |
We need a solution that works for all supported platforms. A few ideas:
- Revert back to using the classic DLL names for all DLLImports (might not work for inbox PowerShell Core on Nano Server)
- Ship an additional NuGet package that contains the API sets PowerShell requires beyond those shipped by CoreCLR
- Modify the missing entries to use the classic DLL while the rest continue to use their API sets
- Leave the unresolved packages broken on Windows 7 and documented those deficiencies as unsupported features.