2

I understand that the new PowerShell 6/core lacks support for Windows GUI libraries, I have developed some important projects in PS-5.1 using the Windows.Forms .NET classes.

Problem: We are planning to upgrade to PowerShell 6 this summer, which means I will lose all the GUI functionalities (developed using Windows.Forms).

Question: What should we do in this situation in order to retain the GUI functionality in our PS apps. Do you envisage Microsoft will provide any alternatives for GUI support going forward?

TIA

9
  • Where did you hear this?
    – EBGreen
    Commented Jan 11, 2018 at 15:27
  • @EBGreen It's pretty common knowledge. PS 6 is based on .Net Core because that's the future of .Net. .Net Core is the rewrite intended for cross-platform .Net development. Certain namespaces, like System.Windows.Forms, are not being implemented in .Net Core.
    – Bacon Bits
    Commented Jan 11, 2018 at 15:29
  • 1
    As of now, I don't see anything that says there will be GUI support in PS6. It would require a significant investment to provide cross platform GUI support I would imagine. If you really want to update what you have currently, I would rewrite the front end in C# or VB.Net then call the powershell bits from there.
    – EBGreen
    Commented Jan 11, 2018 at 15:47
  • 3
    Some of the missing functionality might be implemented in the Windows Compatibility Pack for .NET core, at the moment it's quite limited in what it contains... and it's also uncertain as to what will actually be in it in future. Commented Jan 11, 2018 at 15:57
  • 2
    Can you just load the .Net Framework libraries on Windows? Add-Type -AssemblyName "System.Drawing, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"; Add-Type -AssemblyName "System.Windows.Forms, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" That's supposed to be possible under .Net Standard, but I don't know if .Net Core can load these specific libraries.
    – Bacon Bits
    Commented Jan 11, 2018 at 16:08

3 Answers 3

1

thanks to all who added informative comments.

After a bit of research I discovered that the XAML UI is going to be available in the .NET Core, its support has been added the Universal Windows Platform and Xamarin applications, hence it will be available in PowerShell core/6 for GUI solution development.

Development in XAML appears to be very straight forwards, in fact, in some aspects - easier and quicker than other APIs (especially if you have to hand code the UI components).

0

One question I have is what you mean by "Upgrading" to PowerShell 6? On Windows there is no upgrade. You will run PowerShell 6 side-by-side with your existing version of PowerShell. So, if you want to keep running your old scripts that use GUI stuff, keep doing so in PowerShell 3, 4 or 5.1. If you want to start using PowerShell 6 in order to write scripts that will function on all platforms, then use PowerShell 6 for that. The good news is, you will continue to have both. (for now at least)

3
  • Thanks for your answer, however, for new development, we are looking into taking advantage of the platform independent behaviour of the PS6 without losing the GUI features. There are workarounds but it'd make things a lot easier if a vendor-independent standard GUI-library can be developed (that's a challenge I guess). Commented Aug 17, 2018 at 8:20
  • 1
    I'm not sure how easy that will be considering PS 6 is designed for non-gui Linux, Server Core and Nano Server. That's not to say one is not possible, but it would only work on platforms having some gui subsystem to begin with, thereby negating the rationale of writing for cross- platform. Maybe it's time for someone to bring back ANSI graphics! That was character mode! ;-)
    – CyberJunk
    Commented Aug 18, 2018 at 15:52
  • I absolutely agree with you on ANSI graphics, there should be an internal mechanism to detect if the underlying platform provides GUI, if not, it should automatically render the output in ANSI graphics. This needs to be addressed to the PS6 / Core API developers. Commented Aug 21, 2018 at 10:05
0

It's a russian method, but you can use for the non-PowerShell Core compatible part the default PowerShell "powershell.exe" instead of PowerShell Core "pwsh.exe" in your PowerShell Core script:

Test.ps1:

<# Here you start your script code with your called PowerShell/PowerShell Core: #>
$PSVersionTable
chcp.com 65001;

<# Pause the PowerShell Core code execution and run here a temporary default PowerShell session 
(Non-PowerShell Core) for the Non-PowerShell Core compatible code part: #>
powershell -NoProfile -ExecutionPolicy Bypass -Command {
$PSVersionTable
chcp.com 65001;

[void] [System.Reflection.Assembly]::LoadWithPartialName("System.Drawing");
[void] [System.Reflection.Assembly]::LoadWithPartialName("System.Windows.Forms");

$objForm = New-Object System.Windows.Forms.Form;

[void] $objForm.ShowDialog();

<# Exit the temporary default Non-PowerShell Core session: #>
exit
}

<# And continue here the PowerShell Core script code #>
$PSVersionTable

This works fine for me with Visual Studio Code and also CLI-only execution with System PowerShell (currently: v5.1) and with the PowerShell Core (currently: v6.1.2).

It's not the best solution and Windows only, but a workaround for Windows systems with installed PowerShells.

Not the answer you're looking for? Browse other questions tagged or ask your own question.