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.

By default however, the Windows Azure SDK for .NET doesn’t work this way. To build an Azure project from a build server you need the full SDK installed and suddenly this means the build server is tied to only building projects targeting a specific version of the Azure SDK. If several projects share a single build server then all projects need to be upgraded to the new SDK when one project is upgraded and performing builds on maintenance branches becomes difficult if not impossible.

Simply copying some Azure SDK files into a source-controlled “Dependencies” folder won’t help much either because the (v1.6) build scripts make some assumptions:

• The Azure tools are located at a fixed path under the Program Files folder
• The Azure SDK is located at a path referred to by a HKEY_LOCAL_MACHINE Registry key
• A common .targets file has been installed in the MSBuild extensions folder so every project system-wide references it automatically

Finding and fixing these assumptions is required so that a source-controlled copy of the SDK will work but these assumptions can change (and have changed) in each new version of the SDK so it is important not to be tempted to edit the original files but instead utilise the various hook points in MSBuild to override these assumptions.

Ideally the Azure SDK would just be a Nuget package but until the product team can be convinced to do this, I have published some scripts which allow you to build your own Nuget package of the Azure SDK with all the afore mentioned assumptions fixed. My scripts require a machine with the SDK already installed because I doubt I have the rights to redistribute original files.

The scripts are available in a Mercurial repository hosted on Bitbucket. After cloning or downloading a copy of the repository, just run MSBuild in the root and it will gather the necessary SDK files from your system and produce a Nuget package in the “output” subfolder. From there you might ideally install the package in your Azure project (the *.ccproj file) using this command from the Package Manager Console:

Install-Package -Id Microsoft.WindowsAzure -Source [path to the "output" subfolder]

Unfortunately, at the time of writing this Nuget (also v1.6) doesn’t support Azure projects so slightly more work is required. First, install the package into the target solution’s “packages” folder using the “nuget.exe” command-line interface:

nuget.exe install Microsoft.WindowsAzure -Source [path to the "output" subfolder] -OutputDirectory [path to the solution "packages" folder]

The open the Azure project’s “.ccproj” file for editing in a text editor and add the following line immediately after the opening <Project … > element:

<Import Project="..\packages\Microsoft.WindowsAzure.1.6\tools\Microsoft.WindowsAzure.Nuget.targets" />

Note that the relative path to the “.Nuget.targets” file may be slightly different depending upon project and solution directory structures. You can vote to get Azure support added to Nuget here.

• Queue all the builds immediately and rely upon using a single build agent to serialize the builds. This approach prevents parallelization for improved build times and continues to build subsequent builds even when one fails.
• Check build artifact(s) into source control at the end of the build and let this trigger subsequent builds configured for Continuous Integration. This approach can complicate build definition workspaces and committing build artifacts to the same repository as code is not generally recommended.

As an alternative I have developed a simple customization to TFS 2010′s default build process template (the DefaultTemplate.xaml file in the BuildProcessTemplates source control folder) that allows a build definition to specify the names of subsequent builds to queue upon success. It only requires two minor changes to the Xaml file. The first is a line inserted immediately before the closing </x:Members> element near the top of the file:

    <x:Property Name="BuildChain" Type="InArgument(s:String[])" />

The second is a block inserted immediately before the final closing </Sequence> at the end of the file

    <If Condition="[BuildChain IsNot Nothing AndAlso BuildChain.Length &gt; 0]" DisplayName="If BuildChain defined">
      <If.Then>
        <If Condition="[BuildDetail.CompilationStatus = Microsoft.TeamFoundation.Build.Client.BuildPhaseStatus.Succeeded]" DisplayName="If this build succeeded">
          <If.Then>
            <Sequence>
              <Sequence.Variables>
                <Variable x:TypeArguments="mtbc:IBuildServer" Default="[BuildDetail.BuildDefinition.BuildServer]" Name="BuildServer" />
              </Sequence.Variables>
              <ForEach x:TypeArguments="x:String" DisplayName="For Each build in BuildChain" Values="[BuildChain]">
                <ActivityAction x:TypeArguments="x:String">
                  <ActivityAction.Argument>
                    <DelegateInArgument x:TypeArguments="x:String" Name="buildChainItem" />
                  </ActivityAction.Argument>
                  <Sequence DisplayName="Queue chained build">
                    <Sequence.Variables>
                      <Variable Name="ChainedBuildDefinition" x:TypeArguments="mtbc:IBuildDefinition" Default="[BuildServer.GetBuildDefinition(BuildDetail.TeamProject, buildChainItem)]"/>
                      <Variable  Name="QueuedChainedBuild" x:TypeArguments="mtbc:IQueuedBuild" Default="[BuildServer.QueueBuild(ChainedBuildDefinition)]"/>
                    </Sequence.Variables>
                    <mtbwa:WriteBuildMessage Message="[String.Format(&quot;Queued chained build '{0}'&quot;, buildChainItem)]" Importance="[Microsoft.TeamFoundation.Build.Client.BuildMessageImportance.High]" />
                  </Sequence>
                </ActivityAction>
              </ForEach>
            </Sequence>
          </If.Then>
        </If>
      </If.Then>
    </If>

You can see the resulting DefaultTemplate.xaml file here. After applying these changes and checking-in the build process template file you can specify which builds to queue upon success via the Edit Build Definition windows in Visual Studio:

You can specify the names of multiple Build Definitions from the same Team Project each on a separate line. When the first build completes successfully, all builds listed in the BuildChain property will then be queued in parallel and processed by the available Build Agents. No checking is currently done for circular dependencies so be careful not to chain a build to itself directly or indirectly and create an endless loop.

On the other hand, unless someone is actively monitoring the warnings and notifying the team when new compile warnings are introduced, the technical debt is just going to increase. To address this I thought it would be useful to extend the default build process template in TFS 2010 to compare the current build’s warning count with the warning count from the previous build and fail the build if the number of warnings has increased. The Xaml required for this can be found here. Hopefully this strategy will result in the team slowly decreasing the warning count down to zero and then the “Treat warnings as errors” option can be enabled to prevent new compiler warnings being introduced to the code base.

At the moment this is a very naive implementation – if an increase in warnings fails one build, subsequent builds will pass unless the warning count increases again. I have two ideas for improving this:

1. Compare the current warning count against the minimum warning count of all previous builds.
2. Fail if the minimum warning count has not decreased within a specified time period (eg two weeks).

If I implement either of these two ideas, I’ll update this post but they should both be quite easy to do-it-yourself.

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.

Other people can then see this and contact the user first if they’d also like to test, redeploy or otherwise interrupt a lab environment.

However, if a user manually queues a Lab build from Visual Studio Team Explorer, or a Lab build is triggered by a schedule or a check-in, this marker is not visible and the Lab build will execute, redeploying the environment and most likely upsetting the user who was already using the environment.

As a solution to this, I have modified the default lab build process template to include a new parameter to specify whether the build should fail if the environment has been marked as “in use”.

Thankfully, most of the hard work has already been done in the form of the out-of-the-box Workflow activities for Lab Management, and I just needed to add a small chunk of XAML to the existing LabDefaultTemplate.xaml file in my Team Project’s “BuildProcessTemplates” source control folder. The full customised template is here, but the core of the change was this simple code:

And now the lab build will fail when the environment is marked “in use”…

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.