PowerShell Development Enviroments

From DataSelf Knowledge Base
Jump to navigation Jump to search

Background & History

Every released version of Microsoft DOS and Microsoft Windows for personal computers has included a command-line interface tool (shell). In MS-DOS and Windows 9x the shell was COMMAND.COM. In Windows NT and all later versions of windows the shell interpreter is cmd.exe.

By 2002 Microsoft had started to develop a new approach to command line management, including a shell called Monad (also known as Microsoft Shell or MSH). On April 25, 2006 Microsoft formally announced that Monad had been renamed Windows PowerShell, positioning it as a significant part of their management technology offerings and a component of Windows, not an add-on product. PowerShell v2.0 was completed and released to manufacturing in August 2009, as an integral part of Windows 7 and Windows Server 2008 R2. Versions of PowerShell for Windows XP, Windows Server 2003, Windows Vista and Windows Server 2008 were released in October 2009 and are available for download for both 32-bit and 64-bit platforms.

PowerShell 3.0 is integrated with Windows 8 and with Windows Server 2012. Microsoft has also made PowerShell 3.0 available for Windows 7 with Service Pack 1, for Windows Server 2008 with Service Pack 1, and for Windows Server 2008 R2 with Service Pack 1.

PowerShell 4.0 is integrated with Windows 8.1 and with Windows Server 2012 R2. Microsoft has also made PowerShell 4.0 available for Windows 7 SP1, Windows Server 2008 R2 SP1 and Windows Server 2012.


  • PowerShell Remoting: Using WS-Management, PowerShell 2.0 allows scripts and cmdlets to be invoked on a remote machine or a large set of remote machines.
  • Eventing: This feature allows listening, forwarding, and acting on management and system events. Eventing allows PowerShell hosts to be notified about state changes to their managed entities. It also enables PowerShell scripts to subscribe to ObjectEvents, PSEvents, and WmiEvents and process them synchronously and asynchronously.
  • Scheduled jobs: Jobs can be scheduled to run on a preset time and date.


Cmdlets are specialized commands in the PowerShell environment that implement specific functions. These are the native commands in the PowerShell stack. Cmdlets are specialized .NET classes, which the PowerShell runtime instantiates and invokes when they are run.


http://ps2exe.codeplex.com [old]

File Reflection

$scriptRoot = [System.AppDomain]::CurrentDomain.BaseDirectory.TrimEnd('\')

if ($scriptRoot -eq $PSHOME.TrimEnd('\')) { $scriptRoot = $PSScriptRoot }

[System.AppDomain]::CurrentDomain.BaseDirectory will refer to the location of the executable that is running. Normally that's the $pshome folder (where PowerShell.exe and PowerShell_ISE.exe are located), but when you are using a compiled script generated by PowerGUI, [System.AppDomain]::CurrentDomain.BaseDirectory refers to the folder where the exe is found instead.

Misc Links

  • Windows PowerShell: PowerShell.exe Has a method for specifying a –executionpolicyparameters which accepts one of the Windows PowerShell Execution Policy settings: Unrestricted, AllSigned, RemoteSigned and Restricted. Whatever you specify will take effect for that shell session only, and will override any policy previously set locally with Set-ExecutionPolicy or by a Group Policy Object (GPO).
The Execution Policy isn’t a firewall, and it isn’t anti-malware software. It’s designed to keep uninformed users from unintentionally executing an untrusted script. If you’re specifying the –executionpolicy parameter, by definition, you’re doing so intentionally. You therefore accept the consequences of that action.

Quest PowerGUI =

PowerGUI has a utility that compiles PS1 files to EXE. It's not technically compiling, its "packaging" the PS scripts by wrapping the scripts into a .exe.

If you have code to check the script's current directory ($PSScriptRoot , $MyInvocation.MyCommand.Path , etc), it'll start referring to a temporary folder instead of the folder where the .exe file was located.