When you open PowerShell v3′s ISE (Integrated Scripting Environment) you should see a new Commands pane that wasn’t present in version 2.

This is a built-in example of an ISE Add-on Tool but you can also create your own quite easily. At its simplest an ISE Add-on Tool is a WPF Control that implements the IAddOnToolHostObject interface. To get started writing your own add-on follow these simple steps:

1. Open Visual Studio and create a new WPF User Control Library project. The new project should contain a new UserControl1.
2. Add a new Project Reference to the Microsoft.PowerShell.GPowerShell (version 3.0) assembly located in the GAC.
3. Open the UserControl1.xaml.cs code-behind file and change the UserControl1 class to implement the IAddOnToolHostObject interface.
4. The only member of this interface is the HostObject property which can be declared a a simple auto-property for now.
5. Build the project and find the path of the DLL it produces.
6. Open the PowerShell v3 ISE and load the DLL you have just built, eg:
   Add-Type -Path ‘c:\users\me\documents\project1\bin\debug\project1.dll’
7. Add the UserControl to the current PowerShell tab’s VerticalAddOnTools collection and make it visible (replace “Project1.UserControl1″ below with the full namespace of your control):
   $psISE.CurrentPowerShellTab.VerticalAddOnTools.Add(‘MyAddOnTool’, [Project1.UserControl1], $true)

After following these steps you should see a new, blank pane as an extra tab where the Commands pane normally appears and now you can return to Visual Studio and start adding to the appearance and behaviour of your new add-on tool. There are some other things worth knowing about developing ISE Add-On Tools:

• When your UserControl is added to the ISE, the HostObject property is set to an object almost identical to the $psISE variable and your control uses this to interact with the ISE itself. For example you can manipulate text in the editor, or you can register for events that tell your control when a new file is opened.
• While your UserControl is loaded in the ISE, you cannot build in Visual Studio because the DLL is locked and you need to close the ISE to unlock the file. I recommend adding a small PowerShell script to your project that performs steps 6 and 7 above and change your project’s Debug options in Visual Studio so that the ISE is started and your script is opened when you press F5.
• In step 7 above, your control is added to the VerticalAddOnTools collection but there is also a HorizontalAddOnTools collection and the user can move your control between these two at any time via the ISE menus so make sure you design the appearance of your Add-On Tool to work in both orientations.

Alternatively the Show-UI module for PowerShell includes a ConvertTo-ISEAddOn cmdlet to create the necessary WPF objects natively from PowerShell and avoid the need for a Visual Studio project.

So, given that .NET 4 has excellent support for being able to run most .NET 2 assemblies but PowerShell doesn’t have officially support for .NET 4 yet, how can we safely utilise new .NET 4 functionality from PowerShell without waiting for a new PowerShell release from Microsoft? A quick search of the web will reveal a few different approaches, each with their own major drawbacks:

• Change the system-wide registry setting to load all .NET 2 assemblies under .NET 4 instead for all .NET applications.
• Change the system-wide config files for the PowerShell console, ISE, and Remoting service to use .NET 4 instead for all PowerShell sessions.
• Build a small .NET 4 application to host a PowerShell Runspace in-process as .NET 4.

These options are either have too wide an effect or vary too much from the standard PowerShell experience for me to adopt. What if there was a way, from inside a standard PowerShell 2 session to execute a single command, script block, or script under .NET 4 without touching any upfront configuration, without requiring elevated permissions, and without affecting anything else on the system?

This solution is available in the form of the new Activation Configuration Files feature also introduced in .NET Framework 4.0. By dynamically creating a small config file in a temporary directory then setting a process-scoped environment variable we can easily start a new .NET 4 PowerShell session passing in a ScriptBlock and some arguments and receive the same deserialized objects in return as you would see when using Remoting.

I’ve implemented my first version of this technique as a PowerShell script module available on Gist.GitHub. It includes an Invoke-CLR4PowerShellCommand Cmdlet which behaves just like a very simple version of the built-in Invoke-Command Cmdlet. The module also includes a Test-CLR4PowerShell function demonstrating basic use of the module.

Rather than manually checking the path and version of every assembly referenced by every project in the solution, I wrote a PowerShell script to parse a Visual Studio 2010 solution file, identify all the projects, then parse the project files for the reference information. The resulting Get-VSSolutionReferences.ps1 script is available on GitHub.

Once I had a collection of objects representing all the assembly references I could perform some interesting analysis. Here is a really basic example of how to list all the assemblies referenced by two or more projects:

$Refs = & .\Get-VSSolutionReferences.ps1 MySolution.sln
$Refs | group Name | ? { $_.Count -ge 2 }

It doesn’t take much more to find version mismatches or files that don’t exist at the specified paths, but I’ll leave that as an exercise for you, the reader.

Simply explaining how to determine the path of your ISE profile by checking the value of the $Profile variable from within the ISE would be boring, so instead I wrote another script to automatically download the first script from GitHub, and add it to your profile.

This new script can simply be copied and pasted into the ISE’s Command Pane (Ctrl+D) and your profile will be opened and updated, ready to be saved. Once saved, you can either restart the ISE or simply run ” . $profile ” (without quotes) from the Command Pane.

You will hopefully notice in this new script, that my usual attention to neatness and verbosity has been replaced with terseness due to the purpose of this script being a use once and throw away item. I had considered writing it as a single line but quickly regained my senses.

The way TFS works though, is that all files in your local workspace are marked as read-only until you Check-Out for editing. When working on TFS-managed files in Visual Studio, the check-out is done automatically as soon as you begin typing in the editor. The PowerShell ISE however has no idea about TFS and will let you edit to your heart’s content until you eventually try to save your changes and it fails due to the read-only flag.

But I’ve developed a solution…

I’ve written a PowerShell ISE-specific profile script that performs a few simple things:

1. Checks if you have the TFS client installed (eg Team Explorer).
2. Registers for ISE events on each open file and any files you open later.
3. Upon editing of a file, if it is TFS-managed then checks it out.

The end result is the same TFS workflow experience from within the PowerShell ISE as Visual Studio provides.

However, creating a template from a VM using the SCVMM Administrator Console, without destroying the original VM, is death by a thousand clicks:

1. Shutdown the VM.
2. Dismount any media in the VM’s virtual DVD drives.
3. Clone the VM via an eight-page wizard.
4. Wait for the cloning to complete.
5. Convert the cloned VM into a template with a six-page wizard.
6. Wait for the sysprepping to complete.
7. Restart the original VM.

I tire of such tedium very quickly and as such, I’ve scripted the above process with PowerShell and the SCVMM Snapin. You can access the Export-VMTemplate script I’ve written on gist.github. If you open a PowerShell window from the toolbar in the SCVMM console, you can execute the script like this:

.\Export-VMTemplate.ps1 -VM 'MyOriginalVm' -TemplateName 'NewTemplateName' -LibraryServer 'MyLibSvr'

Hopefully the script itself, or at least some of the concepts within, will be useful to someone else.

However, if you’ve ever tried moving a Team Project Collection you’ll find the documentation is a long list of manual steps, and one of the more tedious steps is Savings Reports. This step basically tells you to use the Report Manager web interface to manually save every report for every Team Project in the collection as an .RDL file. A single project based on the MSF for Agile template will contain 15 reports across 5 folders, so you can easily spend a while clicking away in your browser.

To alleviate the pain, I’ve written a PowerShell script which accepts two parameters. The first is the url for the Team Project Collection, and the second is the destination path to save the .RDL files to. The script will query the Team Project Collection for its Report Server url and list of Team Projects via the TFS API, then it will use the Report Server web services to download the report definitions to the destination, maintaining the folder hierarchy and time stamps. You can access this script, called Export-TfsCollectionReports, on Gist.

Obviously, when you reach the step to import the report definitions on the new server, you’ll want a similar script to help. Unfortunately, I haven’t written that one yet but I will post it to my blog when I do. In the mean time you could follow the same concepts used in the export script to write one yourself.

No problem, I just opened notepad and started typing:

echo class Program { public static void Main() { >"%~dpn0.cs"
echo using (var wc = new System.Net.WebClient()) { >>"%~dpn0.cs"
echo wc.UseDefaultCredentials = true; >>"%~dpn0.cs"
echo wc.DownloadFile(@"http://download.microsoft.com/download/1/1/7/117FB25C-BB2D-41E1-B01E-0FEB0BC72C30/WindowsServer2003-KB968930-x86-ENG.exe", @"%~dpn0.installer.exe");}}} >>"%~dpn0.cs"
"%systemroot%\microsoft.net\framework\v3.5\csc.exe" /out:"%~dpn0.exe" "%~dpn0.cs"
"%~dpn0.exe"
"%~dpn0.installer.exe"

Saved it as a command script and double-clicked it. PowerShell v2 installer downloads and runs, bam!

This would require tweaking for other processor architectures, other operating system versions, or older .NET installations.

Thanks to @tathamoddie for the proxy-friendly fix.

Simply save the following code as a text file and save it with the same name as your PowerShell script but replace the .ps1 extension with a .cmd extension.

@echo off
setlocal
set tempscript=%temp%\%~n0.%random%.ps1
echo $ErrorActionPreference="Stop" >"%tempscript%"
echo ^& "%~dpn0.ps1" %* >>"%tempscript%"
powershell.exe -command "& \"%tempscript%\""
set errlvl=%ERRORLEVEL%
del "%tempscript%"
exit /b %errlvl%

Now if your script is called “Get-Something.ps1”, you can simply run it like this:

Get-Something “c:\some path\some.file” –SecondArg 3.14

I agreed and with an absurdly short amount of preparation presented to a small group online using Microsoft Live Meeting and a shared PowerShell console window. You can watch the presentation on the Oz Alt.NET Community Blog.

The “slides” and example scripts can be downloaded here.