The PowerShell team should ship it's modules via a Module Repository (like NuGet), and add commands for retrieving and installing modules to the Core module. They should use that mechanism to further separate releases from the Windows Server ship schedule. In fact, I suggest that you should externalize *all* of the non-core modules (everything which is currently loaded on-demand) to separate them from the ship schedule in the same way (and for the same reasons) that Help is separated now.Just as the ASP.NET team has been able to accelerate releases of new features and fixes by separating much of their code from the Visual Studio and Windows Server release cycles and putting it into NuGet packages (and shipping NuGet built into Visual Studio), so the PowerShell team could benefit from a similar separation.As a side note, I think it would probably help to create a default profile that did something like:if(!(get-command add-type)) { Install-Module Microsoft.PowerShell.* Update-Help}It would probably be necessary (as with NuGet) for the module repository commands to support using a folder share (or external drive) as a simple module repository (and to open source the core module repository code) so that companies could run module repositories in-house to satisfy the need to get modules onto machines with pre-approval and without internet access. The default repository (and perhaps a list of allowed repositories) would need to be controlled via global policy.
Please wait...