PowerShell Snap-in Support
Using the “Additional Files” feature, if you should add a PowerShell snap-in as a file you can choose to have it automatically registered as part of the package execution process. This feature must be selected for each snap-in file if you have multiple files included. Note that if set to register, the package will simply register it as specified—there are currently no checks performed to verify if another version may already exist on the system.
If you should find that the process of unpacking and installing snap-ins is slowing execution time, you can mitigate this by checking a new option that lets you show a progress message to the user while this work is taking place. This can be a potentially complex operation given your scenario, so we’ve exposed some features to help you reference the snap-ins more easily.
- No Auto-Add – If you have a lot of items you’ll want to call out what you want to reference specifically with code at the top of your script. Doing so avoids adding references to everything registered for each execution. If you choose to have it registered, it will be registered. This option is about establishing a reference to the snap-in from your script.
- Auto-Add for executing user – Choosing Auto-Add will add each snap-in to the PowerShell instance before running your script so that you need not reference them in your code. In this case it will do so for the executing user only.
- Auto-Add for all users – This provides the same benefit as above, but the snap-in can be referenced by any user on the system.
Of course referencing the snap-in for more than the executing user does not make sense for a single script execution, so this feature is geared toward those who wish to permanently install the snap-in on the local system as part of package execution. If you fill in the “Permanent Snap-in Path” field, the installation of the snap-in will be installed to the specified folder and will remain installed after the package execution is complete.
Note: Installation of snap-ins requires admin permission. If the packaged script is using alternate credentials this should not be an issue, but if you are having users run this in their own context be aware that using this feature does not change the security requirements for PowerShell snap-in registration.
64-Bit Support
While you can run 32-bit packaged scripts on 64-bit systems, new to this release is the option to package the script as a native 64-bit package.
From the main settings panel, choose from the following CPU type options:
- 32-bit only – this will still run on 64-bit systems
- 64-bit only – this will run only on 64-bit systems and will fail if executed on a 32-bit system.
- Auto-Detect – this will cause the package to include both 64-bit and 32-bit files which will result in a much larger package, but one that can run natively on both architectures.
Please note that packaged scripts always initially started by a small 32-bit launcher application. After this bit of code runs, the process started will depend on the CPU type selected: If 32-bit, only 32-bit binary apps are in the package and they are executed with no check. If 64-bit, only 64-bit binary apps are in the package and they are executed with no check. Finally, if auto-detect is specified, both 32-bit and 64-bit binary apps are in the package and at execution time the target system is checked and the appropriate ones are used.
Hide PowerShell Console
Many PowerShell scripts will generate a console window and that is fine, but if you are packaging a script that is based on a graphical form (such as one generated by our ScriptForm Designer) checking the option to “Hide PowerShell Console” will ensure that only your form is displayed and not the customary console window along with it.
Filed under: Features | Comments Off on ScriptPackager Enhancements in ASE4
Admin Script Editor 
You must be logged in to post a comment.