PSCX 2.1 and 3.0 Release Candidates Posted

Oisin and I have been busy prepping the PowerShell Community Extensions to support Windows PowerShell 3.0.  With this release, we are providing two packages.  There is a Pscx-2.1.0-RC.zip that is xcopy deployable just like PSCX 2.0.  Just remember to unblock the ZIP before extracting it otherwise you’ll get errors when you try to import the module.  Pscx 2.1 can be used to target both Windows PowerShell 2.0 and 3.0.  In order to do this, Pscx 2.1 is still compiled against .NET 2.0 and it can’t take advantage of any Windows PowerShell 3.0 specific features. 

The second package is Pscx-3.0.0-RC.msi.  This is a traditional Windows installer package.  The benefit of using an MSI is that the user doesn’t have to worry about unblocking the file before installing it.  The MSI file is also Authenticode signed with an extended validation code signing certificate so it should make it past Windows 8 SmartScreen.  I’d like to extend a big thanks to DigiCert for graciously donating the EV code signing certificate to us.

INSTALLATION NOTE: the WiX-based installer modifies the PSModulePath environment variable but the modification doesn’t always seem to be in effect after installation.  If Import-Module Pscx –RequiredVersion 3.0.0.0 fails to load PSCX, import the module by path (C:\Program Files (x86)\PowerShell Community Extensions\Pscx3\Pscx\Pscx.psd1) until you get a chance to reboot.  After that, you shouldn’t have to specify the path.

Another aspect of Pscx 3.0 is that it is compiled against .NET 4.0 and takes advantage of some features specific to Windows PowerShell 3.0.  Over time, we will focus our new feature efforts on the Pscx 3.0 branch.

PSCX 2.1 and 3.0 Side-by-Side Support

With this release, you can install Pscx 2.1 and 3.0 side-by-side.  Note however that if you xcopy install Pscx 2.1 into your user’s Modules directory, PowerShell will find that version of Pscx before the 3.0 version.  In order to ensure you load a specific version of Pscx, use the –RequiredVersion parameter on Import-Module e.g.

Import-Module Pscx -RequiredVersion 3.0.0.0

Support for AllSigned Execution Policy

Each of the two packages above (2.1 and 3.0) supported execution in an AllSigned environment.  All of the script files (*.ps1, *.psm1 and *.ps1xml) have been signed.  Of course, this means you can’t modify these scripts (i.e. to fix bugs) and still run them AllSigned.

New Features

There are not a lot of new features in this release but there are a few handy additions including:

  • Get-Parameter – thanks to Jason Archer for contributing this great way to visual a command’s parameter information.
  • Import-VisualStudioVars – for developers who like to spend their time in PowerShell instead of cmd.exe, this function takes care of importing the build environment for the specified version of Visual Studio.  The 2008, 2010 and 2012 versions of Visual Studio are supported.
  • Start-PowerShell – a wrapper for PowerShell.exe that utilizes the PowerShell parameter parsing engine to make invocation of various flavors of PowerShell (from PowerShell obviously) easier.  While testing the AllSigned support I used this command a lot:
    Start-PowerShell -NoProfile -ExecutionPolicy AllSigned -Version 2
  • Get-ExecutionTime – since PowerShell 2.0, the HistoryInfo object for a command has included both the StartExecutionTime and the EndExecutionTime. This command makes it easy to see the total execution time for any command e.g.:

C:\PS> Get-ExecutionTime

  Id ExecutionTime    HistoryInfo
  -- -------------    -----------
   1 00:00:02.9919258 Get-ChildItem C:\Windows\System32
   2 00:00:00.2650339 Get-Process
   3 00:00:00.2499424 Get-Service

Bug Fixes

Oisin spent a good deal of time fixing issues in the Read-Archive and Expand-Archive cmdlets.  We updated the version of 7z that we are using (to 9.x) and modified the cmdlets to use SevenZipSharp.  I also fixed a number of bugs in Invoke-Elevated (alias su), Set-Writable, Edit-File and type accelerators breaking on PowerShell 3.0.

As you use these release candidates please report any issues to the Pscx CodePlex project.  Thanks for supporting Pscx!

About these ads
This entry was posted in PowerShell 2.0, PowerShell 3.0, PSCX. Bookmark the permalink.

3 Responses to PSCX 2.1 and 3.0 Release Candidates Posted

  1. Pingback: Episode 202 – Antoine Habert talks about PoshBoard « PowerScripting Podcast

  2. PSCX 2.1RC, ReleaseNotes.txt, line 6: “Pscx 2.1 only works with Windows PowerShell 2.1.” I can verify it still works with Powershell 2.0. Although the loadtime during VERBOSE: Loading ‘FormatsToProcess’ from path
    ‘C:\Users\geftest\Documents\WindowsPowerShell\Modules\pscx\FormatData\Pscx.TerminalServices.Format.ps1xml’. is quite slow for me (on 2.0; 3.0 works quick enough)

  3. Thomas S. Trias says:

    It looks like 2.1.0 uses the HelpUri parameter in the CmdletBinding attribute, which causes bad juju in PowerShell 2.0:

    Modules\GetHelp\Pscx.GetHelp.psm1:407: [CmdletBinding(DefaultParameterSetName='AllUsersView', HelpUri='http://go.microsoft.com/fwlink/?LinkID=113316')]
    Modules\Utility\Pscx.Utility.psm1:223: [CmdletBinding(DefaultParameterSetName='AllUsersView', HelpUri='http://go.microsoft.com/fwlink/?LinkID=113316')]

    I will post an issue to the CodePlex site as well.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s