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
1) clarify this aspect in the documentation. More honest advertisement wouldn't hurt as well
2) 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.ServiceModelassembly.Import-WinModule WcfPSand it works.Import-WinModule WcfPSalthough 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 1) clarify this aspect in the documentation. More honest advertisement wouldn't hurt as well 2) provide a parameter to work with modules available in the PowerShell Core's
$PSModulePath. For exampleImport-WinModule WcfPS -Name ModuleName -CoreImport-WinModule WcfPS -Name ModuleName -LocalOnlyor 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.