Script Packager packs new features.

PrimalScript 2009’s Script Packager contains two new target executables and easier manifest handling.

The increasing popularity of PowerShell and the large numbers from the PrimalForms download prompted us to add dedicated targets to PrimalScript’s Script packager:

image

These two new options allow you to package your PowerShell script into a stand-alone exe file. When executed, this .exe will not need a temporary script file or other special access to the file system. They also do not require a console window for anything that really only interacts with Windows or uses Windows Forms.

Since the PowerShell host in these packages is a .NET application, some things are designed differently:

– Packaged data files are unpacked into a common folder, derived from the version information you add to the package. A typical folder may look like this:
  C:\Documents and Settings\All Users\Application Data\SAPIEN Technologies, Inc\WMI Wizard\1,0,0,1

You can find the folder name inside your PowerShell script using the built-in variable $DataPath.

– Scripts packaged with the Script Packager will not execute any profile in order to avoid creating a dependency on the specific profile on your machine.

– The executable’s command line can be accessed as a string in $CommandLine. Each individual parameter is enclosed in quotes so that spaces in parameters are preserved.

– The exit code from your script can be communicated to the outside world by setting the $ExitCode variable inside your script.

Manifests are becoming a must have for any executable running under Windows Vista and above, even if you do not need the elevation feature this can provide.

PrimalScript 2009’s packager provides more than just a spot to add a manifest:
image

It defaults to adding a generated manifest, and contains the settings you see in the picture above. In most cases the default manifest should suffice for your application, but you can still bring your own.
And yes, these options are available for all packages, not only the new PowerShell targets.

Oh and one more thing….

image

Running a Windows Forms application side-by-side with it’s packaged version shows the slight difference in UI elements.

The packaged version uses the latest common controls and styles, whereas just running the script uses the plain old Windows 2000 style buttons. Just in case you care about such things…