-
Notifications
You must be signed in to change notification settings - Fork 8.1k
Closed
Labels
Area-Maintainers-Buildspecific to affecting the buildspecific to affecting the buildIssue-Enhancementthe issue is more of a feature request than a bugthe issue is more of a feature request than a bug
Milestone
Description
Summary of the new feature/enhancement
Today, we don't have the PowerShell built-in modules published, so it's hard for an application that hosting powershell to ship the built-in modules along with the application.
Built-in modules are needed for hosting application to use ForEach-Object -Parallel, which creates separate Runspaces with InitialSessionState.CreateDefault2() and thus force module loading instead of using the built-in spanins.
It's the same for PSThreadJob module, or any other modules that create Runspace using the same API.
We run into this in Azure Functions, and then in PS sub kernel in dotnet-interactive.
Now, we just have to download the needed module manifests (utility, management) from GitHub powershell repo, and it doesn't really work because
- dotnet-interactive build a global tool that should work on all platforms
- the manifest is not platform agnostic, and there is no way to include both Unix/Windows in the global tool and make the right choice at runtime.
SeeminglyScience and mklement0
Metadata
Metadata
Assignees
Labels
Area-Maintainers-Buildspecific to affecting the buildspecific to affecting the buildIssue-Enhancementthe issue is more of a feature request than a bugthe issue is more of a feature request than a bug