SAPIEN Script Packager updates and new features.

The Script Packager in PrimalScript 2016 gets an update with the next service build (7.2.95). Since this service build changes the locations where your executable files are generated and some new options are available, we thought we’d let you know about these changes before they are actually released.

Based on your feedback, the script engine selection in the Packager settings was too confusing. So we updated the user interface to minimize the number of selections and provide you with a preview of what this selection will do.

Furthermore, as many of you indicated that you still need to support 32 bit machines, this new packager version supports building 32 and 64 bit executables at the same time. Additionally, we added a native Windows platform option, which will always execute the correct version, depending on the current platform. This means you have four options:

1. Microsoft Windows 32 bit, which will generate a 32 bit executable.
2. Microsoft Windows 64 bit, which will generate a 64 bit executable.
3. Microsoft Windows 32 and 64 bit, which will generate a 32 bit and a 64 bit executable.
4. Microsoft Windows Native, which does the same as above (with different naming) but also creates a starter executable, which will launch the correct version for you.

Since the packager can now generate multiple targets with the same name, it can no longer place these files side-by-side with your script. Instead, the executable files are generated in a platform specific folder under a common folder. The common folder can be specified in the packager options and defaults to “bin”. We suggest you stick to that name to keep things uniform, but you can, of course, change it if necessary.

Let’s assume we package a file called “CoolApp.ps1”. Where will the executable file end up?

Depending on your choice, the file CoolApp.exe will be in bin\x86 for 32 bit and bin\x64 for 64 bit. If you selected 32 and 64 bit, well, you will get both files generated in their respective folders.

But what about the last option? The native platform option?

Choosing this build target will put all the files in a folder called bin\Any platform. You will get a CoolApp.exe, CoolAppx86.exe and CoolAppx64.exe. Additionally, .config files are generated for each of them if you checked that option.
The CoolAppx86 and CoolAppx64 files are your actual packaged script. The CoolApp.exe file is a starter application that will execute the right package for the current platform. For your application to work, you must install or deploy all three files together. The starter application receives the same icon, digital signature and manifest as the packaged files, so a shortcut to that file will create the same experience.

We have also added Windows 10 as a target restriction to PrimalScript. All newly generated executables using the default templates are now marked as Windows 10 applications. Additionally, when restricted to a specific version, the executables display the expected and encountered versions in the error message.

The option for auto-incrementing the file version was moved to the Version Information tab.

Oh, and one more thing.

A great many users indicated that they dot source files with common functions. Since these are external to a packaged script, they needed to be deployed with the executable. That created the need to create an installer for an otherwise simple application, required a review or change of script execution policies and, last but not least, opened the application up for user intervention by editing the external script files.

This is why we added an option to resolve dot sourced files while packaging. If the option is enabled, the code of the external scripts gets injected into the packaged script when building the executable.

• Files specified with or without single and double quotes are supported. Files that do not exist will issue a warning. If you have a dot source statement inside a comment block, the file will be inserted into the comment block.
• Using a line comment will prevent a file from being resolved.
• If you need to resolve only some but not all external files, you can use a different case for the file extension.
  . ./include/lib.ps1 will be resolved by the packager,
  . ./include/lib.PS1 will not be resolved.

To make this clear, the statement is case sensitive, the actual filename’s case is not relevant.

As always, questions and comments are welcome. And yes, all these changes will come to PowerShell Studio as well very soon.

 
Follow @SAPIENTech