With moving to .Net Std 2.0 and the PR to enable PSCore6 to load assemblies from the GAC, the missing piece to enable PSCore6 to replace the need for Windows PowerShell (majority of scenarios anyways) is to make it simpler for users to find and use in-box Windows modules. Currently, PSCore6 has no knowledge of the legacy Windows PowerShell PSModulePath. Since we know we don't have 100% compatibility with in-box modules (PSSnapIns, for example are not supported at all), it seems we should consider an opt-in approach. Alternatively, maybe we should have a Windows Compat module that has a whitelist of validated modules that work with PSCore6?
cc @joeyaiello @HemantMahawar
With moving to .Net Std 2.0 and the PR to enable PSCore6 to load assemblies from the GAC, the missing piece to enable PSCore6 to replace the need for Windows PowerShell (majority of scenarios anyways) is to make it simpler for users to find and use in-box Windows modules. Currently, PSCore6 has no knowledge of the legacy Windows PowerShell PSModulePath. Since we know we don't have 100% compatibility with in-box modules (PSSnapIns, for example are not supported at all), it seems we should consider an opt-in approach. Alternatively, maybe we should have a
Windows Compatmodule that has a whitelist of validated modules that work with PSCore6?cc @joeyaiello @HemantMahawar