From script to server – Deploying solutions with PrimalScript 2014 (Part 1)
If you take a look at the new 2014 version of PrimalScript you will discover a new tab on the ribbon interface: “Deploy”
This tab combines three major stepping stones for deploying your scripting solutions:
1. The Script Packager that you all know from previous versions of PrimalScript. Of course this wouldn’t be much of a new version if there weren’t any upgrades.
2. The new MSI builder, which allows you to take your scripts, packages, modules and all the supplemental files you may need and wrap them into a professional grade installer package.
3. Last but not least PrimalScript’s deployment functionality lets you copy your completed package with whatever add-ons you may have to any desired location. You can also execute any number of additional commands to accommodate the deployment mechanism you have in your network environment.
In this first installment of this blog post series we will look into the script packager and its new features.
Some of the settings for the packager will look familiar to you. The usual suspects are all here, Engine selection, STA mode for PowerShell, credentials, signing and so forth. Where it gets interesting is the Engine type selection. You will find that there are a few more options available with this new version:
If you go through the list you will find everything you had in PrimalScript 2012 and then some. Most notably are the “Any platform” engines for PowerShell. If you don’t have any specific platform dependencies in your script, you can package it now so that the same executable will run on 32 bit Windows versions as well as 64 bit Windows versions. Of course it will always run in mode native to the machine.
If you are wondering why there are no specific PowerShell V4 engines, don’t worry. The hosts labeled as V3 work perfectly fine on computers with PowerShell V4 installed. The engine really isn’t any different as far as our hosts are concerned.
The version page also will not hold much of a surprise if you are familiar with the packager of previous PrimalScript versions. So we will skip right to the interesting part:
So this is all new. You can restrict the packaged executable to only run under certain conditions. If your solution is only meant for Windows 8 and higher and their server equivalents, check the two top boxes in the list. Running the package on any other platform will just result in a message that this package was not meant for that particular platform.
User name, MAC address, Machine Name and Domain all accept semicolon separated lists that allow you to restrict execution of this package to the conditions you specify. So for example JOE;Calvin;Hobbs in the user field will require to have the logged on user to have one of those three specific usernames. The same applies correspondingly to the other fields.
Allowing only one instance will make any secondary launch of your executable exit right away. Because of the mechanism used to detect previous instances this only applies to the same user. Different users logged on to the same server can execute their own instance independently.
Last but not least, some additional options to run command pre- or post-packaging
If you need some kind of pre-processor for your script or you want to do something to the final executable, add your commands here. They will be executed in the sequence defined and one after another rather than in parallel.
The auto-increment file version option will save you the trouble of having to remember to increment the version number each time a package is created.
Now that you have set up all the parameters for your package, what do you do next?
You have three additional functions in the Packager group: ‘Build’, ‘Build & Run’, and ‘Run’.
‘Build’ applies all your settings and creates the actual executable file. ‘Run’ executes that file. If you picked a command line engine then the package is executed in a shell window. Depending on the file packaged, this is either a PowerShell console or a regular cmd window. If you picked a form or Windows engine, the file is executed directly.
‘Build & Run’? Well, I think you can figure that one out…
Questions? Comments? Please feel free to let us know how you feel about this in the comment section below. For questions and discussions, please use our support forum as usual.