PowerBoots (Next Generation UI) WPF for PowerShell slides http://ff.im/-xYqJD

I read through the pdf this morning and hope he’s putting out more info and examples on the codeplex site (I’ll have to check later). I hope it gets some follow through, as most projects started never go to completion.

Well, that night (next morning) I was up early and being crazy productive. Reading everything in sight and knocking out todo’s on my Remember the Milk list for both work and around the house. Heck, I even baked some cinamon rolls for the Mrs. and I. Well, in the time that it took the rolls to heat up the combination of Powershell + Google + Visual Studio Team Blogs finished the script. Dang, that was productive.

As always, us scripters stand on the shoulders of those blazing before us. So, a million thanks to those who did the heavy lifting and sat down to blog about it (James Manning & Peter Provost).

Side note: I had the pleasure of meeting Peter out at the Dev11 ALM in Redmond last spring, so it was a real trip to see his blog and face come up as a hit on the search

Here’s what the updates look like in 2010:

On to the code…

# turned the below from James Manning's Blog: 
# http://blogs.msdn.com/b/jmanning/archive/2006/09/28/776141.aspx
# into a function
function get-tfs {
    param(
        [string] $serverName = $(throw 'serverName is required')
    )

    begin
    {
        # load the required dll
        [void][System.Reflection.Assembly]::`
            LoadWithPartialName("Microsoft.TeamFoundation.Client")

        $propertiesToAdd = (
            ('VCS',
                'Microsoft.TeamFoundation.VersionControl.Client',
                'Microsoft.TeamFoundation.VersionControl.Client.VersionControlServer'),
            ('WIT',
                'Microsoft.TeamFoundation.WorkItemTracking.Client',
                'Microsoft.TeamFoundation.WorkItemTracking.Client.WorkItemStore'),
            ('CSS',
                'Microsoft.TeamFoundation',
                'Microsoft.TeamFoundation.Server.ICommonStructureService'),
            ('GSS',
                'Microsoft.TeamFoundation',
                'Microsoft.TeamFoundation.Server.IGroupSecurityService')
        )
    }

    process
    {
        # fetch the TFS instance, but add some useful properties to make life easier
        # Make sure to "promote" it to a psobject now to make later modification easier
        [psobject] $tfs = `
            [Microsoft.TeamFoundation.Client.TeamFoundationServerFactory]::`
            GetServer($serverName)
        foreach ($entry in $propertiesToAdd) {
            $scriptBlock = '
                [System.Reflection.Assembly]::LoadWithPartialName("{0}") > $null
                $this.GetService([{1}])
            ' -f $entry[1],$entry[2]
            $tfs |
                add-member scriptproperty $entry[0] `
                    $ExecutionContext.InvokeCommand.NewScriptBlock($scriptBlock)
        }
        return $tfs
    }
}

# found the next 2 calls from my man Peter Provost's blog: 
# http://www.peterprovost.org/blog/post/Fun-with-PowerShell-and-TFS-Work-Items.aspx 
# and tweaked it a tad

#$tfs = get-tfs http://mytfs:8080 # this is for TFS 2008 (my work system)
$tfs = get-tfs http://dell-xps:8080/tfs # this is for TFS 2010 (my home system)

#$tfs #to echo out the connection as a test.

# get the workitem ID that you want
$wi = $tfs.wit.GetWorkItem(1)

# update the workitem history with your info (using a TDstamp here for multiple runs)
$wi.History = "This is a test of updating the history from powershell $(Get-Date)"

# echo it out to your session so you can see it.
$wi.History

# save it back to the tfs system
$wi.Save()

# and done.

there was only one patch that I needed to run as I got to the basic configuration wizard, it pointed me here to check for any important updates since the product was released, and the TFS team / Brian Harry had posted about this a while back: http://code.msdn.microsoft.com/KB2135068

I also ran in the latest TF powertools (Sept 2010 here) for all of their awesome goodness:

http://visualstudiogallery.msdn.microsoft.com/en-us/c255a1e4-04ba-4f68-8f4e-cd473d6b971f

I chose to add the Powershell commandlets doing a custom install and installing everything. You will need to logoff or  restart your vista or win7 system for the shell extensions to take effect.

But it really is that dead easy… and now i’ve got everything rolling… time to pick back up on the education.

I’ll be following this path today:

from the VS2010 online docs:

http://msdn.microsoft.com/en-us/library/dd286491.aspx

from Brian Harry’s blog:

http://blogs.msdn.com/b/bharry/archive/2009/10/01/tfs-2010-for-sourcesafe-users.aspx

Readme for Microsoft Visual Studio Team Foundation Server 2010: You can find the most recent readme on the Microsoft Web site.

let’s see how it goes…

Take a peek.

Link to the podcast Keith Albright mentioned it in.

Gotta make that site readable!

That’s him squinting to read the old site with it’s dark colors

This helps define all of the built versions of a given build to the development and QA staff that went into a given deployment so that there’s no ambiguity as to what version of the binary went out into a given environment (heh, assuming that they are setting the version). I just used Program Files here as a test directory.

#Get-ApplicationVersions            

Get-ChildItem -Recurse 'C:\Program Files' |
?{$_.extension -eq '.exe'} |
Select-Object -ExpandProperty VersionInfo |
Export-Csv C:\temp\ApplicationVersions.csv            

Invoke-Item C:\temp\ApplicationVersions.csv

If you don’t already, I’d suggest subscribing to Martin’s blog and also his podcast contributions (Radio TFS)

TechEd 2010 North America – Martin Woodward

http://www.nivot.org/2010/05/21/PowerShellISEHackingChangeDefaultSaveEncodingToASCII.aspx

Thanks for that Oisin!

Now if we can only change the default of >> and the write-*’s without having to Out-File -Encoding everytime <grrr>…. sneaky powershell.

(Note – This cheats by poaching the good try catch lesson from Test-PsRemoting script by the man himself, Lee Holmes)

<#
.Synopsis
This script will check to see if the current right version of .Net is installed on the target server.
.Description

.Parameter $ComputerName

.Example
PS> .\Check-DotNet.ps1 -ComputerName $ComputerName
.Example
PS> Import-Csv .\TESTEnvironment.xls.csv | select -ExpandProperty servername | .\Check-DotNet.ps1

.Link
about_functions
about_functions_advanced
about_functions_advanced_methods
about_functions_advanced_parameters

.Notes
NAME:      Check-DotNet
AUTHOR:    whereami\lavoieph
LASTEDIT:  5/21/2010 2:38:05 PM
#Requires -Version 2.0
#>

[CmdletBinding()]
param(
[Parameter(Position=0, ValueFromPipeline=$true)]
$ComputerName = ‘.’ # default to localhost
)

Process {
$DotNetVer = “Microsoft .NET Framework 3.5 SP1″ # set to whatever you need

function Check-DotNet
{
param(
[Parameter(Mandatory = $true)]
$ComputerName
)

try
{
$errorActionPreference = “Stop”
$result = Invoke-Command -ComputerName $ComputerName -ScriptBlock {
Test-Path “HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\$DotNetVer” }
}
catch
{
Write-Verbose $_
return $false
}

## I’ve never seen this happen, but if you want to be
## thorough….
if($result -ne 1)
{
Write-Verbose “Remoting to $computerName returned an unexpected result.”
return $false
}

$true
}

$Object = New-Object PSObject -Property @{
ComputerName = $ComputerName
DotNetVer = $DotNetVer
HasDotNetVer = Check-DotNet $Computername
}
$Object | Format-Table -AutoSize ComputerName, DotNetVer, HasDotNetVer
} # end process