You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jun 16, 2021. It is now read-only.
There is nothing stopping PowerShell core of installing a module that requires the full .net framework. For example, I've developed this WcfPS and within it I do heavy use of .net code from the System.ServiceModel assembly.
If I install the module from the Windows PowerShell environment then I can do Import-WinModule WcfPS and it works.
If I install the module from the PowerShell (Core) environment then I can't do Import-WinModule WcfPS although it won't complain.
When I first read about WindowsCompatibility I understood that it will offer the ability to execute any module that depends on the full .net framework, as people work with from their environment PowerShell Core. While experimenting with WindowsCompatibility module, I am positively surprised by the fact that is based on the implicit importing of modules but I'm also disappointed because it has failed to communicate the following two points:
It is designed primarily to load the modules available in the up to version 5.1 Windows PowerShell installation.
It doesn't offer a seamless experience when working from withing PowerShell Core console when a person wants to work with a non-default module. In essence, I need to open the Windows PowerShell console, install a module from there and then try to use it from PowerShell Core console.
I suggest one of the following
clarify this aspect in the documentation. More honest advertisement wouldn't hurt as well
provide a parameter to work with modules available in the PowerShell Core's $PSModulePath. For example
There is nothing stopping PowerShell core of installing a module that requires the full .net framework. For example, I've developed this WcfPS and within it I do heavy use of .net code from the
System.ServiceModel
assembly.Import-WinModule WcfPS
and it works.Import-WinModule WcfPS
although it won't complain.When I first read about WindowsCompatibility I understood that it will offer the ability to execute any module that depends on the full .net framework, as people work with from their environment PowerShell Core. While experimenting with WindowsCompatibility module, I am positively surprised by the fact that is based on the implicit importing of modules but I'm also disappointed because it has failed to communicate the following two points:
I suggest one of the following
$PSModulePath
. For exampleImport-WinModule WcfPS -Name ModuleName -Core
Import-WinModule WcfPS -Name ModuleName -LocalOnly
or just another cmdlet name for simplicity and keeping all the others clean.
In the second case, the cmdlet shouldn't accept a computer name any longer, as it needs by design to create a session to
localhost
.Let me know what your thoughts are especially on the second's suggestion parameter name. I think that it shouldn't be this difficult to implement.
The text was updated successfully, but these errors were encountered: