Skip to content
This repository has been archived by the owner on Jun 16, 2021. It is now read-only.

Work with windows based modules that are installed in the PowerShell core setup #71

Open
Sarafian opened this issue Mar 21, 2019 · 0 comments

Comments

@Sarafian
Copy link

Sarafian commented Mar 21, 2019

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
  • Import-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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant