Powershell cmdlets about tech-radar HOT 11 CLOSED

For Linux support we might want to Explore PowerShell Core

from tech-radar.

I've been having a bit of a play with it. It's a lot like working with .NET Standard. Main differences are:

• There's a different shell executable you have to install and use, pwsh.exe.
• If you stick to standard cmdlets, you'll be fine.
• If you use anything that's Windows-specific, you're likely to hit a couple of issues:
  • Things like registry access are more likely to result in permission problems. e.g. dir hklm: fails by default, though dir hkcu: is fine..
  • Your script won't work on non-Windows platforms. Kinda goes without saying, really.
• If you use any .NET types (e.g. via New-Object), you need to be careful to limit yourself to type in .NET Standard.

If you stick to the above rules, your scripts will probably work in both PowerShell and PowerShell Core. If you're deploying any scripts for customer to use, it's probably best to run automated tests under both powershell.exe and pwsh.exe.

from tech-radar.

Good question!

Since they seem to be the default, I guess Powershell cmdlets should be in Adopt.

Not so sure on "plain old commandline". My gut reaction is Endure.

Does raise questions regarding potential Linux support for things in future, maybe?

from tech-radar.

I do think whether we should be providing a plain commandline in addition to cmdlets is an interesting question, and not necessarily one I have strong feelings on.

Users seem to be all over the spectrum on this, with some enthusiastic about using PowerShell for all the things, and others needing help from Support to adapt simple worked examples.

from tech-radar.

I wonder if it's worth exploring going PowerShell first, and then provide a more limited command-line offering via a .cmd script to expose basic use cases, rather than creating a full-blown console application? Might be nice to try this on something like SQL Clone.

from tech-radar.

If we're considering promoting PowerShell cmdlets, should we also be expressing guidance on script modules vs binary modules?

from tech-radar.

related issue we've just run into on Figleaf (where we currently have a plain commandline): how do we parse commandline options?

We have RedGate.Legacy.Commandline (the old Shared.Utils implementation) currently in Endure, ideally moving to Retire at some point.

In the past we've used NDesk.Options which seemed to work pretty well, although I don't know of any products which are actively using it now (since they've moved to/been replaced with powershell)

from tech-radar.

Sounds like we've got agreement on this. Are any teams in a position to explore PowerShell Core?

Adopt:

• PowerShell cmdlets

Explore

• PowerShell Core

Endure:

• Plain old command lines (we prefer PowerShell cmdlets for new stuff)

from tech-radar.

We're currently looking into building some masking cmdlets for Figleaf, so we can probably spend some time figuring out what Powershell Core is as well

from tech-radar.

I'm not sure how well binary PowerShell modules are supported under PowerShell Core. They were always a bit of a second-class citizen in PowerShell. We'd probably have to look into converting https://github.com/red-gate/RedGate.PowerShell to target .NET Standard.

from tech-radar.

Ah yes, I should have said we were building a binary module. (and we are also inheriting from RedGate.Powershell since I've just been copying what our other products do)

from tech-radar.