From script to server – Deploying solutions with PrimalScript 2014 (Part 2)

Last time we looked at the new packager options in PrimalScript 2014. You can find the article here:

If you look at the deploy tab again, you see an installer group that was not an option in any of the previous PrimalScript versions


This new feature allows you to wrap your scripts, packaged executables, associated scripts, modules, configuration and binary files in a proper Microsoft Windows Installer database for easier deployment. If you have participated in our MSIWizard community preview you may already be familiar with a lot of this. Let’s examine the options we have.


Most of the settings on this dialog are pretty straightforward, but lets go through them anyway:

Product Name: That is what will show up in the control panel “Programs and Features” list. So it’s important that you pick a name your users will recognize.

Product Version: Each installer needs to have a version number. That allows the update feature to work properly. It prevents older copies from installing over a new version, it prevents re-installing an already installed version and it will trigger an uninstall/install if a previous version is installed. To make keeping track of this number easier we added a feature where the version number for the installer gets extracted from an executable file. Most commonly that will be the file you created with the packager, but it can be any executable file with a version resource. But of course you can still enter your version numbers manually if you like.

Company Name: That name is visible in the “Programs and Features” applet as well. It also determine the folder name if you application gets installed under the Program Files folder.

Product Type: Your selection here, together with the “64 Bit installer” and “Install for all users” options determines where your files are installed.

The following table shows the locations for a 64 bit OS with “Install for all users” selected

Product Type

32 bit

64 bit

Windows Application C:\Program Files (x86)\Product Name C:\Program Files\Product Name
Script Application C:\Program Files (x86)\Product Name C:\Program Files\Product Name
PowerShell Module %Windir%\SysWOW64\WindowsPowerShell\v1.0\Modules\Product Name %Windir%\System32\WindowsPowerShell\v1.0\Modules\Product Name


This table shows the locations for a 64 bit OS with a current user only install selected

Product Type

32 bit

64 bit

Windows Application C:\Program Files (x86)\Product Name C:\Program Files\Product Name
Script Application %HomePath%\Script Applications\Product Name %HomePath%\Script Applications\Product Name
PowerShell Module %HomePath%\WindowsPowerShell\Modules\Product Name %HomePath%\WindowsPowerShell\Modules\Product Name


The folders for a 32 bit OS are the same to those shown here, except that “Program Files (x86)” is always “Program Files” and “SysWOW64” is always “System32”.


Product Icon: This icon file will be embedded in the MSI file and shown in “Programs and Features” with your product.

64-Bit installer: Checking this option prevents installation on 32 bit OS. It also registers COM components as 64 bit components and changes some folder names as indicated earlier.

Install for all users: This will install the application and its shortcuts for all users on a system. In most cases this option will require administrative privileges. It also affects the install folder location for some product types.

Require Administrator: Checking this option will cause Windows Installer to prompt for elevation on Windows Vista or higher. The type of prompt depends on your local UAC (User Access Control) settings and the currently logged on user.

Require PowerShell V3:  With this option checked, the installer checks if PowerShell V3 is installed. If it is not, a prompt to install WinRM 3.0 is displayed and the installation is aborted.



This page of the MSI settings allows you specify which files go into your installer. To make this easier, you can just drag and drop them from Windows Explorer onto this list. The little blue arrows allow you to arrange the files in any order you like, but note that this has no actual impact on the installation.

Create Shortcut to: Select the file you want to create a shortcut to in the Windows Start menu. At this time you can only select one file. Typically this is your main executable or script file. For PowerShell modules you can link to the help file for example.

MSI Name: The filename for your MSI. This only affects the actual MSI file and not any of the internal names.

Output Folder: This specifies the location where you want the MSI file to be created. It can be any existing folder. If you choose a network location, please make sure this location is available when building your installer.



Last but not least, you have the option to apply a digital signature to your installer.

Certificate: A certificate is either a code signing certificate installed in your local store or a PFX file you specify in this field. You can browse for a PFX file using the file browse button(image_thumb1 ) or a certificate using the certificate button (image_thumb3 )

Password: If you specified a PFX file for code signing it may require the use of a password. If so, please enter it here.

Timestamp URL: This URL is used to create a time stamp for the signature used to sign the file. Logging the time of signing allows your MSI file’s signature to remain valid even after the certificate expired.

Use the Signing Wizard to sign the MSI file: If your certificate does not fit the above criteria or if you need to sign with a different signature each time you are building a MSI you can use the Microsoft Signing Wizard. Any settings entered above will be ignored and the wizard will guide you through the signing process.


The buttons here let you easily build and test your installer. Build, install and uninstall from here until you have it all ready to go. Next time we will look at the Deployment options which will help you distribute your solution to others.