Repository navigation
Platform-specific set of Modules (and assemblies) #1122
Description
Activity
My thought on this is that if they're part of PowerShell (this repo), then they need to build everywhere, and error gracefully (e.g. platform not supported messages) where not supported.
That's a reasonable approach.
How can we achieve "fails gracefully part"?Currently it fails like this
Get-LocalUser : Unable to load DLL 'api-ms-win-security-lsapolicy-l1-1-0.dll': The specified module could not be found. (Exception from HRESULT: 0x8007007E) At line:1 char:1 + Get-LocalUser + ~~~~~~~~~~~~~ + CategoryInfo : NotSpecified: (:) [Get-LocalUser], DllNotFoundException + FullyQualifiedErrorId : System.DllNotFoundException,Microsoft.PowerShell.Commands.GetLocalUserCommandI see two aspects to this problem:
- DLLs that will never be supported outside Windows
- DLLs that will eventually be supported outside windows, but are not yet supported
For #2, leaving them in the package and temporarily adding a platform-specific graceful error message seems appropriate.
For #1, if it will never be supported, I think we should not ship it in the non-Windows packages. For example, why should the Linux package include Windows eventing files and registration? The solution to this seems to be in adjusting the lists of files that are processed when creating installers.Also, the best way to do this is blocked on one our long outstanding issues, #673, which requires https://github.com/dotnet/cli/issues/465, and is listed as an external blocker under #667.
2 remaining items
For short-term solution, we will do a post-build step that removes certain things from Linux and Mac build. I think we should put it under
Start-PSBuild -Publishonly. Andy Jordan (@andschwa) does it sound reasonable?sergei (@vors), yes that's reasonable.
Removing blocked given that we have a short-term solution.
- added a commit that references this issue
on Aug 6, 2026
Currently we control set of build artifacts only for CoreCLR vs FullCLR build.
We are getting more assemblies/Modules from #1031 and #1118
They are currently getting published for Linux / OS X and they fail in runtime, if user tries to use them.
Example: LocalAccount.
We need to find a right approach to create different artifacts output for different configurations.