PowerShell Studio 2015: Service Release v4.2.96

November 10th, 2015 by David Corrales
Last updated on November 10th, 2015

 

We released a new service build for PowerShell Studio 2015 (v4.2.96).

 

In this release we introduced another new feature:

 

Create Module from Help

If you aren’t familiar with PowerShell HelpWriter, it is a tool that lets you create external PowerShell help files (MAML) for existing modules or from scratch. PowerShell HelpWriter can be a useful design tool for creating modules, by allowing you to plan out your module’s cmdlets and its parameter sets before writing a single line of PowerShell code.

This write-help-first design approach is made much easier with PowerShell Studio’s Create Module from Help File feature.

image

Create a new project and select the help file and give your module a name:

SNAGHTML108e6ab

Now you have a new module containing the help file and the skeleton functions defined in the help file.

image

 

Build Button for Module Projects

We added a build button to the Project Panel for module projects.

image

The build button will build the module and export the module to:

My Documents\WindowsPowerShell\Modules

 

Improved Syntax Coloring for Classes

We improved syntax coloring for classes. Enumerator and class types are now colored.

image

Support for New Operator

We also added PrimalSense support for .NET types and the New operator that was introduced in PowerShell V5.

image

Improved Theme

We improved the theme coloring of the panels and buttons (especially for those who like the dark theme):

image

 

Packager Engine Parameters Update

We made some changes to the packager engines so that it is easier for you to handle parameters. Now when you have a parameter block in your script, you can pass named parameters to the executable and it will pass the values to the script for you.

For example, if your script has a parameter block such as:

  param($param1 = 'default', [int]$param2, [int]$param3)

You can call the packaged executable using named parameters:

  packaged.exe –Param1 "value 1" –Param2 2 –Param3 1

Now there are a few caveats:

1. Arguments/ Parameters passed to the executable are going to be strings and not the original objects. Luckily PowerShell can convert strings to integers and other types behind the curtains.

2. You can’t pass an array of values:

       -Param1 1, 2, 3

Instead you will have to convert it to a string and process the values in your script.

       -Param1 "1, 2, 3"

Then to have to split the value:

       $param1 –split ','

3. You can’t use switch or Boolean parameters. Instead you will have to use a parameter of type int or string and check for specific values

 

We also added a new variable $EngineArgs (string[]) which contains the arguments passed to the executable.

For example, if you pass the following arguments to the packaged executable:

  packaged.exe –Param1 value1 –Param2 "value 2" –Param3 1

The $EngineArgs variable will contain:

-Param1
value1
-Param2
value 2
-Param3
1

You can use the $EngineArgs variable if you wish to process the packager arguments manually. The $EngineArgs variable makes for a better alternative than using the $Commandline variable, which you would have to parse from scratch.

In an upcoming article we will cover using parameters in packaged executables in more detail.

 

Please continue providing your feedback. Many of the new features included in the service builds are suggestions from users like you. Therefore if you have any suggestions or feature requests, please share them with us on our Wish List and Feature Requests forum.

 

UPDATE: v4.2.97 Corrects a coloring issue with the designer.

 

 
[Google+]   [Facebook]   [LinkedIn]   [StumbleUpon]   [Digg]   [Reddit]   [Google Bookmark]  

Tags: , , ,