Script Packaging Step-by-Step: Choosing a Script Engine

This first article in our SAPIEN Script Packager series walks you through the Script Engine settings.

When you open the SAPIEN Script Packager for the first time, the number of options can be a bit daunting. But fear not; most items have a reasonable default and those that don’t are actually not that complicated.

For this article series, we will focus on PowerShell. Long-time users of PrimalScript are commonly aware of the options for VBScript, JScript, Windows Script Host, etc., so we will skip these. But if you have any questions, please feel free to comment below.

Before you can package any script, you need to tell the packager which platform you intend to run the script under (32-bit, 64-bit, or both), and the PowerShell version. Please note that these options have to be selected and saved before you can build a package; the build button will remain inactive until you have specified the minimum required settings.

The platform choices of 32-bit and 64-bit are pretty simple. Unless you still have some 32-bit computers in your network, you can usually set this to 64-bit and not worry about it. If you need a 32-bit version of your application, you can select “Microsoft Windows 32 Bit”, or “Microsoft Windows 32 and 64 Bit”. In the latter case, the packager will create a packaged executable for each platform in a different folder. The folder names are x86 for 32-bit, and x64 for 64-bit.

There is another option if you need both 32-bit and 64-bit versions of your application: “Microsoft Windows Native”. Instead of creating two separate applications and rolling them out depending on the platform, you can create a version that always starts the right thing. Please note that this is not available for PowerShell 7 at this time.

This option creates three executables in a folder named “Any platform”. For example, if you specified an output name of “MyScript”, SAPIEN Script Packager will create three executable files: MyScript.exe, MyScriptx86.exe, and MyScriptx64.exe. When you run MyScript.exe, it will determine the current operating system’s platform and launch the appropriate version of your application (32-bit or 64-bit).

Now on to the different choices of applications:

Command line:

A command line executable opens a console and writes its output there. Because it is an executable file, it runs from a cmd console just as well.

Silent:

As the name implies, this type of packaged executable does not produce any output whatsoever. It has no console, and any console output your script might generate is suppressed. Please note that any Windows forms or message boxes you use will still show. This type of package is best suited for command line scripts you want to run quietly, such as scheduled tasks.

Windows Application:

Packaging your script as a Windows application pipes the output to a text box; this can be very useful for long running scripts, producing a large amount of output. The application remains running after your script is finished, giving you the option to examine the output for saving or printing. For a more detailed discussion of the abilities of this type of package, please see Creating a Windows Application with PowerShell.

Windows Application (Dark Mode):

Dark Mode is just a modification of the Windows Application packager engine, using dark colors instead of the Windows defaults. Use either one, depending on your preference.

Windows Forms:

Almost any form script or project you create with PowerShell Studio should use this packager engine. Any output your script writes to standard output or error output is suppressed, including progress messages. The assumption is that you will provide output vital for the operation of your application within its user interface.

Windows Service:

A Windows Service is code usually running in system context rather than as a specific user; without user interface and operating in the background. Because Windows Services have specific requirements,
scripts for a Windows Service must contain certain defined entry points—so please use the templates provided in PrimalScript and PowerShell Studio.

Windows Services must be installed in a specific way so that the operating system is aware of them; simply running the resulting packaged executable file will not suffice.

Please refer to the following articles for more information:

Windows Service packages are only available for Windows PowerShell at this time.

Windows Tray Application:

A Windows Tray Application runs in your system tray, typically on the bottom-right where your WiFi and current date and time are displayed.

For more information, please see Creating a System Tray Application with PowerShell.

Windows:

This is the simplest way of converting a script to a Windows application. It has no console popping up, so it is less jarring to a ‘regular’ user. Any script output is directed to a message box. While this is not a feasible option for scripts with a lot of output, it is ideal for scripts that take some time to operate and then inform the user that the task is finished. For example, Write-Output “Backup completed”. Likewise, you can use this for scripts that only communicate a specific failure but otherwise run silently.

STA Mode

Last but not least, you see an option for STA mode, which only applies to PowerShell engines. STA Mode is checked by default, and we highly recommend leaving it checked unless you have a very specific reason not to do so. As a general rule in all packager options, if something is checked by default—it is for a reason. There may be situations where it is necessary to turn something Off, but generally, it is On because it is needed. This is covered in PowerShell Studio: Knowing when to use STA Mode.

If your script uses any type of UI and/or standard Windows dialogs, STA Mode needs to be On. It is of absolutely no detriment to leave it On if you do not use any UI elements.

Stay tuned to our blog for more SAPIEN Script Packager installments.

Feedback

Questions or comments? Please feel free to post in the comment section below or in our support forums.

SAPIEN Technologies