Support request for Linux PowerShell Core

[LaxmiPrasadBotla]

Import module have to happen without errors in Linux. I have this module path listed in PS $env:PSModulePath.

$ Import-Module FormatPx -Verbose
VERBOSE: Loading module from path '/root/XX/library/FormatPx/FormatPx.psd1'.
VERBOSE: Loading module from path '/root/XX/library/FormatPx/FormatPx.dll'.
Import-Module : Could not load type 'Microsoft.PowerShell.Commands.OutPrinterCommand' from assembly 'Microsoft.PowerShell.Commands.Utility, Version=6.2.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'.
At line:1 char:1

• Import-Module FormatPx -Verbose
• CategoryInfo : NotSpecified: (:) [Import-Module], TypeLoadException
• FullyQualifiedErrorId : System.TypeLoadException,Microsoft.PowerShell.Commands.ImportModuleCommand

Version Info:
$PSVersionTable

Name Value

---

PSVersion 6.2.0
PSEdition Core
GitCommitId 6.2.0
OS Linux 3.10.0-957.el7.x86_64 #1 SMP Thu Nov 8 23:39:32 UTC 2018
Platform Unix
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
WSManStackVersion 3.0

[KirkMunro]

Thank you for reporting that issue. I'll have to isolate the OutPrinter functionality so that it's loaded on Windows only, since PowerShell Core does not support Out-Printer.

[ChrisLynchHPE]

I just came here to report the same thing. However, since you and I had an email conversation a long time ago about format display being a defect within PowerShell, shouldn't PowerShellCore finally have fixed this, without needing your FormatPX classes overloading Format-* Cmdlets?

That being said, I'm hoping a version of FormatPX can be released that addresses this soon. I'm in the process of investigating migrating my .Net Framework 4.6 class library to .Net Standard 2.0 and PowerShell Core 6 (ideally 6.2.2 or newer) in the next few months.

[KirkMunro]

@ChrisLynchHPE I hear you loud and clear. Been very busy with other work, but I'm coming back to this now. One big question I've been asking myself is should I keep FormatPx standalone or should I submit an RFC to have it included by default in PowerShell since PowerShell is open source. I don't mind supporting these modules standalone, but since they override default cmdlets I think a better solution would be integrated. I may end up doing both in the short term, to get support for this in PowerShell Core while I start a discussion on an RFC about fixing formatting in PowerShell to address all of the issues that FormatPx addresses.

[ChrisLynchHPE]

I would LOVE to see this as an enhancement to PowerShell Core itself, and the default Cmdlets. I can certainly help provide use cases in the discussion with the PowerShell team.

[ChrisLynchHPE]

@KirkMunro, is the pull request PowerShell/PowerShell#10430 you have made to the PowerShell project related to this? If so, I'd pull down your branch and test a build of 7.0-Beta with my module.

[KirkMunro]

Loosely. It allows objects such as ErrorRecord, ScriptBlock, etc. to be piped to Format-* cmdlets without needing -Force. It doesn't do anything to allow piping beyond a Format-* cmdlet. You're more than welcome to test it out to see how it works.

Actually @ChrisLynchHPE, one place I could use your help is in figuring out if there is enough justification for FormatPx bits in PowerShell 7+.

Today FormatPx provides several key values:

1. It allows scripters to pipe beyond a Format-* command, which makes it easy for function/script authors to return data with a specific format while still being ready for use in a pipeline.

2. It solves the heterogeneous formatting problem, allowing you to return some information in a table, other information in a list, etc. from a single function, and the objects render the way you expect them to regardless of the order in which the objects were returned from the function.

If I recall correctly, you leverage both of these key values in your use of FormatPx today (please correct me if I'm wrong).

While each of those capabilities are important, if I were to start from scratch, I don't think I would design this module the same way today, with the main reason for that being performance. FormatPx overrides the Format-* cmdlets, generating the formatted representation of data and attaching it to that data before it is passed on. That generation takes time. You can see that very simply by comparing the runtime for a command that produces formatted data vs. the runtime for a command that captures that data without producing the formatted data. For example, this output was taken from a PowerShell 7 preview build:

  Id     Duration CommandLine
  --     -------- -----------
   1        0.095 $p = gps -id $PID
   2        0.022 $propsAll = $p.PSObject.Properties.Name
   3        0.040 $propsSome = $propsSome = $propsAll | where {$_ -notin @('Modules','MainModule','Parent')}
   4        0.018 $ps = gps
   5        0.207 $x = $ps | fl
   6        3.569 $x = $ps | fl $propsSome
   7       20.223 $x = $ps | fl $propsAll

That clearly demonstrates that retrieving the process list is much, much faster than actually producing the formatting for that process list. Also, that's just the default formatting. If you use Format-List *, you'll see the initial duration take quite a bit longer: about 20 seconds on my machine in PowerShell 7. That's slow. It's not dog slow like PowerShell 5.1 where the same command takes 1 minute and 20 seconds, again, on my machine, but, wow that's slow.

Given the performance hit with formatting, I think a better design would be to allow commands to identify the format that they want output (I'm thinking this could be done as part of the OutputType attribute), and the data returned would capture the desired format without actually generating it. Generation of the format would happen when the objects were actually output to the console. This approach would allow a caller to pipe a command that uses a predefined format to another Format-* command, getting that format when the data is output.

Something that would help me out @ChrisLynchHPE is if you could refresh my memory on exactly how you're using FormatPx with your module today so that I make sure that I have that top of mind while I think on this some more.

[KirkMunro]

@ChrisLynchHPE: FYI, I just filed PowerShell/PowerShell Issue #10463 that shows my current line of thinking about this module and how I could move it forward into PowerShell.

[KirkMunro]

FYI for folks want this fixed:

The PowerShell Team just merged a PR into PowerShell 7 that adds Out-Printer back into PowerShell. The reason FormatPx wouldn't work in PowerShell Core without modification was because Out-Printer was missing. I suspect this will make FormatPx magically "just work" in PowerShell 7, but I will need to test it out to make sure.

[mi-hol]

@ChrisLynchHPE did you perhaps get a chance to test with a nightly build of pwsh after the PR got merged or are you waiting for 7.0.0-preview.6 to be released?

[KirkMunro]

@mi-hol: I've tested this using a build with latest, and there is another issue, but that's due to how workflow was removed from PowerShell 7. I need to get that fixed ASAP, and then I'll retest.

[KirkMunro]

Ok, quick update on this:

Out-Printer was indeed added back in PowerShell 7, so that's not a blocking issue, and testing confirms this; however, in another PR, one of the internal types that I use underwent a name change, so I need to update FormatPx to support the new name (already done locally), and there is a regression in PowerShell 7 because the public WorkflowInfo class was removed. We're discussing putting that back right now in PowerShell/PowerShell#11053.

Hopefully this will allow me to support PowerShell 7 with this module once these issues are out of the way, and once I get my code signing certificate back again.

Stay tuned.

[ChrisLynchHPE]

I have not tested with any pre-release of PowerShell 7. Is there no way for FormatPX to be supported in PowerShell 6? I mean, who even uses Out-Printer???

[KirkMunro]

Sure it's possible. I even begun working on it, moving Out-Printer into a separate DLL that would only be loaded on Windows. There are just some complications about me releasing right now (need an update code signing cert, and I have something else I need to get before I can make that happen). Plus, PowerShell 7 is much better than 6, so if I can get it working there easily, that would be my preference. Once 7 is out (and it's almost there) I see very little benefit to supporting 6.

[KirkMunro]

@ChrisLynchHPE Is PowerShell 6.x support a high-priority item for you?

[ChrisLynchHPE]

Considering I have not even begun to look at PowerShell 7, I would say yes. If there is a significant reason to encourage users to move to 7, that would be good to know. I can certainly start looking at PowerShell 7 over the upcoming US holiday break, which hopefully is RC by then.