Quick access

PS2EXE-GUI: "Convert" PowerShell Scripts to EXE Files with GUI

Overworking of the great script of Ingo Karstein with GUI support. The GUI output and input is activated with one switch, real windows executables are generated. With Powershell 5.x support and graphical front end.
Now here: https://github.com/MScholtes/TechNet-Gallery

Hello Jamal1337,
the issue with PS2EXE and PowerShell 6 or 7 is the underlying .Net Core. PS2EXE compiles a frame C# program containing the PowerShell script. .Net Core (and so PowerShell 7) does not deliver a compiler anymore in its base installation, one has to install the SDK to get one ("Roslyn").
And once there is the compiler, the calling method has changed completely. I do not know how to implement this without weeks of work.
If someone has a good idea how to make it "cheap", please tell.
Greetings
Markus

Hi Markus, first off, I love the script, and I think it's great in making running powershell scripts more accessable for the regular folk out there, so I use it a lot work related..
But here's the thing, a while ago I put together a script and used your tool to convert it into an exe, but I have not used it in quite a while since it's purpose was very specific.
Now someone has approached me about that program/script and has made me an offer to buy it from me, whereas normally I'm all for free and open software, this case is a little bit different, also I could just sell him the ps1 but he seems to prefer the wrapped exe version, so my question is, is there anything in the PS2EXE license that would restrict or hinder me from selling the eventual exe file of my program? Or do I still keep all the same rights over the exe file as I would the original ps1 file?
Also, just wondering, is it possible to disable obfuscation?

Hell Eanske,
PS2EXE is published under the MS-LPL License that you can study above. The conditions allow to compile your script and sell the resulting executable as long as you do not remove any copyright Terms. But please see all condition terms.
What do you mean with obfuscation? There is no obfuscation in PS2EXE, the original script is converted to Base64 to avoid errors with special characters. You can get the original script by calling the compiled executable with the parameter /extract.
Greetings
Markus

Oh sorry I mean base64 yes, I was under the impression that was considered obfuscating..
The thing is the resulting exe doesn't seem have any other copyrights on them other than the one I gave it before compiling.
I'm a sysadmin, but not much of a legal expert unfortunately, but is the compiled exe result considered part or a portion of the PS2EXE software?
Because would that mean 3C is applied from the license?
Kind regards

Hello Eanske,
it is fine for me if you sell your compiled script. But the MS-LPL license is still binding for the part of PS2EXE in your compiled script. One could divide the base64 part and the rest of the executable and use the rest according to the MS-LPL license.
If I was you, I would not care.
Greetings
Markus

Hello Sathish,
I do not know the reason for this behaviour but it might has to do with variable scopes that changed from Powershell V2 to V3. Please try to use $SCRIPT:MainForm instead of $MainForm in your example above.
Greetings
Markus

Hello AW L,
beginning with Powershell V3 Microsoft made a weird implementation of Start-Transscript with mixing the code into the Powershell and the underlying host. So I did not implement this commandlet and have no plans to do so.
Sorry for that.
Greetings
Markus

I think you misunderstood me. JacquesFS's code would still be required. But if the same application is run from cmd then it would result in a '.' ($ScriptPath = "." }). if that segment is replaced with (shortened): $ScriptPath = icm {cmd /c echo %CD%} it will return the ScriptRoot correctly.

Hello Nick Zimmermann,
I did not misunderstood you. The situations where JacquesFS's solution returns an empty string are when the compiled scripts are called from a command line in the directory of the script. In this situation returning a '.' is correct and working. But if you insist on having a fully qualified path, you can use your solution.
(Please do not tell anybody that our solutions return the current directory, which need not be the directory of the script)
Greetings
Markus

I found the solution to support TLS 1.2 with Powershell V2.
I add those lines in my script:
$TLS12 = [Enum]::ToObject([System.Net.SecurityProtocolType], 3072)
[System.Net.ServicePointManager]::SecurityProtocol = $TLS12
I tried to replace 3072 by 12288 to support TLS 1.3, but that doesn't work. Anyway, TLS 1.2 is fine for me.

Hello,
This little program is great for handing completed PS scripts to helpdesk folks without having to explain how to launch PS and run the script. I have noticed though that if I run the EXE using shift+right click > run as different user, when the PS script has completed, the process is not exiting. It stays in task manager until I kill it. Does not seem to happen if I just double click the file.
Any way to fix this so the process closes as expected when done?

Hello nickp85,
this sounds a bit complicated. I think there is an issue with using PoshRSJob in PS2EXE. PoshRSJob starts a powershell runspace pool without closing it. Powershell.exe forcefully closes all runspaces on exit, but PS2EXE is running in a runspace by itself. So it waits for the runspaces to close what never happens, this leads to an infinite wait.
I found no easy way to tell PoshRSJob to close its runspaces, so I see two workarounds:
1. Change the runspaces of PoshRSJob to use its own threads
Search for the file Start-RSJob.ps1 in the module directory of PoshRSJob, if installed for the AllUsers context the path is "C:\Program Files\WindowsPowerShell\Modules\poshrsjob\1.7.4.4\Public\Start-RSJob.ps1".
Edit the file and insert the line
$RunspacePool.ThreadOptions = "UseNewThread"
in the line before
$RunspacePool.Open()
(line 524 as of version 1.7.4.4)
Since PoshRSJob runspaces use their own threads now they can be distinguished from PS2EXE's runspace and get closed on exit.
If you want the runspaces to close faster at the end replace
$RunspacePool.CleanupInterval = [timespan]::FromMinutes(2)
with something like
$RunspacePool.CleanupInterval = [timespan]::FromSeconds(10)
two lines before the expression mentioned above.
2. Close the runspaces manually on exit of your script
Put the following line on all places of your script where an exit can occur:
Get-Runspace | ?{ $_.Id -ne [System.Management.Automation.Runspaces.Runspace]::DefaultRunspace } | ?{ $_.RunspaceAvailability -lt 3 } | %{ $_.Dispose() }
This line closes all runspaces that are not "Busy" and obviously not the default runspace (you would crash the script engine then). I would not recommend to do this in regular scripts.
Hope this helps.
Greetings
Markus