According to KB926140, this will fail if you installed Powershell before you installed SP2 (or upgraded to R2) because the latter update includes the former.  MSI patching is fun like that.  So if you want v2.0 goodness, it’s time to do some surgery.

WARNING: this is completely unsupported by Microsoft.  It happened to work for me.  YMMV.

First you need to dig up a copy of PSCustomSetup.exe.  If you have a machine that already has PS v1.0 on it, you’ll find this tool in %windir%\$NtUninstallKB926139$.  (Note: the KB number may be 928439 on Vista, but I don’t have a Vista machine to say for sure.  Use your “gci -filter” skillz.)  Or you can dig it out of the v1.0 install package.  You might also try to grab a copy of spuninst.inf that’s appropriate for your OS, just to sanity check you aren’t missing anything, though we will be hacking our own…

Basically, we need to manually replay the steps that the uninstaller would have taken.  Ordinarily, the .inf file spells this out in a vaguely human-readable format.  Thanks to the efforts of some folks around the net[1][2][3], I was able to come up with a comprehensive list.  Technically it can vary from OS to OS, or even machine to machine, but you wouldn’t be here unless you had the 2003 R2 issue in particular – XP and Vista aren’t affected since PS is not part of their service packs.  Plus, it’s fairly easy to abstract out the machine-specific paths with an environment variable here & there.  Thus, my instructions:

1) Copy the PSCustomSetup.exe you found to a temporary directory on the affected machine.

2) Copy/paste this first script block into a file named uninstall.cmd and save it into the temporary directory.

pushd %windir%\Microsoft.NET\Framework\v2.0.50727
ngen.exe uninstall "System.Management.Automation,Version=1.0.0.0,Culture=neutral,PublicKeyToken=31bf3856ad364e35,ProcessorArchitecture=msil" /silent /nologo /NoDependencies
ngen.exe uninstall "Microsoft.PowerShell.ConsoleHost,Version=1.0.0.0,Culture=neutral,PublicKeyToken=31bf3856ad364e35,ProcessorArchitecture=msil" /silent /nologo /NoDependencies
ngen.exe uninstall "Microsoft.PowerShell.Commands.Management,Version=1.0.0.0,Culture=neutral,PublicKeyToken=31bf3856ad364e35,ProcessorArchitecture=msil" /silent /nologo /NoDependencies
ngen.exe uninstall "Microsoft.PowerShell.Commands.Utility,Version=1.0.0.0,Culture=neutral,PublicKeyToken=31bf3856ad364e35,ProcessorArchitecture=msil" /silent /nologo /NoDependencies
ngen.exe uninstall "Microsoft.PowerShell.Security,Version=1.0.0.0,Culture=neutral,PublicKeyToken=31bf3856ad364e35,ProcessorArchitecture=msil" /silent /nologo /NoDependencies
ngen.exe uninstall "System.Management.Automation.resources,Version=1.0.0.0,Culture=en,PublicKeyToken=31bf3856ad364e35,ProcessorArchitecture=msil" /silent /nologo /NoDependencies
ngen.exe uninstall "Microsoft.PowerShell.ConsoleHost.resources,Version=1.0.0.0,Culture=en,PublicKeyToken=31bf3856ad364e35,ProcessorArchitecture=msil" /silent /nologo /NoDependencies
ngen.exe uninstall "Microsoft.PowerShell.Commands.Management.resources,Version=1.0.0.0,Culture=en,PublicKeyToken=31bf3856ad364e35,ProcessorArchitecture=msil" /silent /nologo /NoDependencies
ngen.exe uninstall "Microsoft.PowerShell.Commands.Utility.resources,Version=1.0.0.0,Culture=en,PublicKeyToken=31bf3856ad364e35,ProcessorArchitecture=msil" /silent /nologo /NoDependencies
ngen.exe uninstall "Microsoft.PowerShell.Security.resources,Version=1.0.0.0,Culture=en,PublicKeyToken=31bf3856ad364e35,ProcessorArchitecture=msil" /silent /nologo /NoDependencies
popd

PSCustomSetupUtil.exe /uninstall "System.Management.Automation,Version=1.0.0.0,Culture=neutral,PublicKeyToken=31bf3856ad364e35,ProcessorArchitecture=msil""
PSCustomSetupUtil.exe /uninstall "Microsoft.PowerShell.ConsoleHost,Version=1.0.0.0,Culture=neutral,PublicKeyToken=31bf3856ad364e35,ProcessorArchitecture=msil""
PSCustomSetupUtil.exe /uninstall "Microsoft.PowerShell.Commands.Management,Version=1.0.0.0,Culture=neutral,PublicKeyToken=31bf3856ad364e35,ProcessorArchitecture=msil""
PSCustomSetupUtil.exe /uninstall "Microsoft.PowerShell.Commands.Utility,Version=1.0.0.0,Culture=neutral,PublicKeyToken=31bf3856ad364e35,ProcessorArchitecture=msil""
PSCustomSetupUtil.exe /uninstall "Microsoft.PowerShell.Security,Version=1.0.0.0,Culture=neutral,PublicKeyToken=31bf3856ad364e35,ProcessorArchitecture=msil""
PSCustomSetupUtil.exe /uninstall "System.Management.Automation.resources,Version=1.0.0.0,Culture=en,PublicKeyToken=31bf3856ad364e35,ProcessorArchitecture=msil""
PSCustomSetupUtil.exe /uninstall "Microsoft.PowerShell.ConsoleHost.resources,Version=1.0.0.0,Culture=en,PublicKeyToken=31bf3856ad364e35,ProcessorArchitecture=msil""
PSCustomSetupUtil.exe /uninstall "Microsoft.PowerShell.Commands.Management.resources,Version=1.0.0.0,Culture=en,PublicKeyToken=31bf3856ad364e35,ProcessorArchitecture=msil""
PSCustomSetupUtil.exe /uninstall "Microsoft.PowerShell.Commands.Utility.resources,Version=1.0.0.0,Culture=en,PublicKeyToken=31bf3856ad364e35,ProcessorArchitecture=msil""
PSCustomSetupUtil.exe /uninstall "Microsoft.PowerShell.Security.resources,Version=1.0.0.0,Culture=en,PublicKeyToken=31bf3856ad364e35,ProcessorArchitecture=msil""
PSCustomSetupUtil.exe /removeenvvariable PATH "C:\WINDOWS\system32\WindowsPowerShell\v1.0"
PSCustomSetupUtil.exe /removeenvvariable PATHEXT ".PSC1"
PSCustomSetupUtil.exe /wmsettingchange

rd /s /q %windir%\$NtUninstallKB926139$
rd /s /q %windir%\system32\windowspowershell

pushd %windir%\assembly\gac_msil
rd /s /q System.Management.Automation
rd /s /q Microsoft.PowerShell.ConsoleHost
rd /s /q Microsoft.PowerShell.Commands.Management
rd /s /q Microsoft.PowerShell.Commands.Utility
rd /s /q Microsoft.PowerShell.Security
rd /s /q System.Management.Automation.resources
rd /s /q Microsoft.PowerShell.ConsoleHost.resources
rd /s /q Microsoft.PowerShell.Commands.Management.resources
rd /s /q Microsoft.PowerShell.Commands.Utility.resources
rd /s /q Microsoft.PowerShell.Security.resources
popd

3) Open a CMD window, navigate to the temporary directory, and run the script.  Watch for errors.  (Post to the comments…)  Make sure it’s a 64-bit CMD window if you’re on x64 Windows.

4) Copy this block of text to a file named uninstall.reg and save it to the temporary directory.  Run it and accept the “yes, I really want to do this” prompt.

Windows Registry Editor Version 5.00

[-HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell]
[-HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\OID\EncodingType 0\CryptSIPDllCreateIndirectData\{603BCC1F-4B59-4E08-B724-D2C6297EF351}]
[-HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\OID\EncodingType 0\CryptSIPDllGetSignedDataMsg\{603BCC1F-4B59-4E08-B724-D2C6297EF351}]
[-HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\OID\EncodingType 0\CryptSIPDllIsMyFileType2\{603BCC1F-4B59-4E08-B724-D2C6297EF351}]
[-HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\OID\EncodingType 0\CryptSIPDllPutSignedDataMsg\{603BCC1F-4B59-4E08-B724-D2C6297EF351}]
[-HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\OID\EncodingType 0\CryptSIPDllRemoveSignedDataMsg\{603BCC1F-4B59-4E08-B724-D2C6297EF351}]
[-HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\OID\EncodingType 0\CryptSIPDllVerifyIndirectData\{603BCC1F-4B59-4E08-B724-D2C6297EF351}]
[-HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\HotFix\KB926139]
[-HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates\Windows Server 2003\SP2\KB926139]
[-HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates\Windows PowerShell 1.0]
[-HKEY_CLASSES_ROOT\.ps1]
[-HKEY_CLASSES_ROOT\.ps1xml]
[-HKEY_CLASSES_ROOT\.psc1]
[-HKEY_CLASSES_ROOT\Microsoft.PowerShellConsole.1]
[-HKEY_CLASSES_ROOT\Microsoft.PowerShellScript.1]
[-HKEY_CLASSES_ROOT\Microsoft.PowerShellXmlData.1] 

5) Install Powershell v2.0

6) Clean up the temp dir.

Success?  Hope so – if not, it’s probably time to nuke that install!  (or at minimum, restore from backup)  Good luck everyone. 

Note: these instructions do not remove shortcuts from the Start Menu or anywhere else.  You’ll need to do that yourself.

[1] http://groups.google.com/group/microsoft.public.windows.powershell/browse_thread/thread/51a54e7de0ed5d1f/eaba9eb2c0d772ec

[2] http://blogs.msdn.com/powershell/archive/2007/01/09/behind-powershell-installer-for-windows-xp-windows-server-2003.aspx

[3] http://marcoshaw.blogspot.com/2008/06/powershell-v2-ctpctp2-error-error.html

Bzzt.  I think we don't support remote Windows debugging for Silverlight.  Can anyone confirm or deny?

It sure doesn’t work for me.  I can choose a browser from the list of processes and “Silverlight code” from the list of debuggers, but I always get “Unable to attach to the process.”

• My first public demo, by way of Brian Harry’s blog
• Keith Hill’s early explorations

And rightfully so: most of the operations you want to do locally are already possible without any special tools.  The “Powershell snap-in system” we know and love today was created to help IT admins manage their servers – even today, only a brave few developers have completely replaced cmd.exe at their daily workstation.

Nevertheless, we shouldn’t be satisfied to have our TFS cmdlets live in their own little world.  Luckily, all the info we could ever want about a TFS version controlled item – including its local state – comes packaged in the ExtendedItem object.  Even more fortuitously, if you revisit the exploration of QualifiedItemSpec with an eye for detail, you’ll notice that one overload of ToQualifiedItem() is not like the others.*  In the constructor where ExtendedItem decays into QualifiedItem, the properties saved into the resulting tuple include LocalItem and VersionLocal instead of more familiar ones like ServerItem.  This is not a coincidence :) 

Let’s sum up what we know so far.  Native TFS objects are funneled down the pipeline by stripping them to bare essentials about the items they represent (QIs); these serve as a common interface between cmdlets.  When an ExtendedItem is stripped down, the next cmdlet will use the local filename & local version info as its parameters.  Get-TfsItemProperty is the cmdlet that returns ExtendedItems.  Capiche?

Time to put our newfound knowledge into action.  If you’ve also been following the last several posts on file manipulation in powershell, these examples will hopefully inspire an “aha!” moment.

[Note that I have get-tfsitemproperty aliased to ‘tfprop’ rather than ‘tfproperties’ as it appears in a default install of the Power Tools.]

Are we having fun yet?!

So far we’ve only really exercised the filename part of the QI.  Equally interesting things happen when you take advantage of the special ability that Get-TfsItemProperty offers to manipulate the local version.

[Microsofties: think bbpack / jjpack]

Opens up a whole new world of TFVC scripting mania, wouldn’t ya say?

*I’ll admit the one for GettingEventArgs is a little funky as well.  Here, the choice of properties to expose came down to UX / gut feel.  TargetLocalItem is usually what you want to see; it tends to be the “final result” of mainline operations, surviving things like Rename and Undo fairly well.  But it’s not always the best choice.  Obviously when it’s null we need a backup; good old ServerItem will do.  It’s [almost always] guaranteed to be present, but it’s  not always perfect either – now you have the occasional strange appearance of server paths in your list of local files being touched by the Update.  Finding the right info gets really tricky really fast: was TargetLocalItem null because of a pending Delete, because it’s cloaked or otherwise excluded from our workspace, or because we’re undoing a pending Branch or Merge?  That’s just one example.  The logic behind which name tf.exe displays in which scenario is actually one of the more complex pieces of the app.  With powershell we can accept “good enough” since the object model lets you manipulate things to your heart’s content.

1. Points to “C:\program files (x86)” regardless whether you’re in a 32-bit or 64-bit process.
2. Exists on legacy 32-bit operating systems.

Sounds like a common thing you’d need: to find the location where 32-bit programs are installed regardless of any other factors.  Powershell’s $env:ProgramFiles(x86) variable comes close, but even if it were present on 32-bit OSes -- honestly not sure about that -- the parentheses in the variable name present a nasty parse problem.  No amount of quoting or backtick`ing or $()’ing got me the result I was looking for.  If you have more patience than me, have at it.

And oh yeah, did I mention I was shopping for a better null coalescing operator than the one that comes with PSCX?  Note to PSCX folks: I hate wrapping stuff in scriptblocks when there’s no real need for them.  Thanks, Richard’s pinky finger.

So anyway, I resorted to putting this abomination in my $profile:

Yes, it’s ugly and nonstandard (in the sense that I can’t rely on this being present in other people’s script environments)…suggestions welcome...

As you can probably tell, you’ll need some other code for this to compilebe interpreted successfully.

[and oh yeah, we finally get to leave the world of CSRSS.exe behind.  Ctrl+V!  sweet blessed Ctrl+V!]

Naturally, I started the customization process by scouring the web.  Keith’s "Yank Line” function quickly joined my Custom menu.  (though I map it to Ctrl+K, a vestige of muscle memory from Pico.  thanks for the memories, crappy Solaris boxes at Duke!)  Soon after came a function templater from Andy Schneider, handy especially since the new v2 syntax is pretty verbose.  And of course Lee’s syntax highlighter, without which the pretty code you’re seeing would not be possible – though in full disclosure I’ve heavily modified it.  (first to fit into a Module, then to remove the Apartment Threading overhead that’s thankfully not relevant in the ISE, and finally to take the currently selected text instead of the whole document)

Any other recommendations for $profile inclusion?  Or know how to override a keyboard shortcut, for that matter?

Back to the point of this post.  My work style tends to involve dozens of tabs, files scattered all over the place, saved & not, until I clean things up hours later.  So naturally the built-in file management features of ISE have got to go!  With the help of the $psise object model, the get-fullpath script I introduced last time, and liberal additions to the ISE profile (Microsoft.PowerShellISE_profile.ps1), it’s not hard to greatly beef things up:

• quick Open from the interactive prompt, including rich pipeline support seen in previous posts
• ditto for Close
• Close All But This
• Undo Close with a full FIFO stack of everything you’ve ever closed using my functions
• Save All
• Copy Full Path to clipboard

As you can see, the Close function ended up much uglier than expected.  Powershell limitations/bugs or programmer ignorance?  Suggestions welcome.  Powershell verb-noun Nazis need not apply.  Functions which live only in the $profile for quick consumption at the interactive prompt and/or ISE shortcut key are not obligated to follow the rules for discoverability, IMO.

* note that the built-in documentation for Resolve-Path is wrong!  as of CTP3, it’s claiming the output is a string

Plus, you may be working with 3rd party tools that obey none of the above conventions. 

For example, with the TFS Power Tools, Hyung had the foresight to add string[] to the list of types we can convert to QualifiedItems behind the scenes using extra constructors, but we still don’t support the ValueFromPipelineByPropertyName idiom that’s needed to make non-trivial filesystem objects flow.  Furthermore, the objects we output are native TFS types, which were never designed with Powershell in mind.  Most of the time there’s little overlap between these objects and non-TFS cmdlets, but a big exception is the LocalItem property of the ExtendedItem object returned by “tfprop.”  In hindsight, we should have added a NoteProperty that aliased it to Path.  (…or FullName, or Name, depending on whether the PS guys make up their mind :) )

Then there are tools that have nothing at all to do with Powershell.  Some sort of wrapper script is going to be required regardless, but without consistency in the kind of input your wrapper can expect, it can get needlessly complex.

My solution to all of the above is outlined below.  Time to let the code do the talking:

Who knew that ValueFromPipelineByPropertyName worked on aliases?  I didn’t.  I thought it would be nice, but since I didn’t see it documented anywhere, my initial sketch for this function used a ton of ugly ParameterSets as a workaround.  Somewhere in there I decided to try Aliases; lo and behold, it works!  Yay.

This function is useful on its own – if nothing else I use it as a wholesale replacement for resolve-path, whose behavior on UNC paths is bizarre in my opinion – but its real value is as a helper.  For example, a couple snippets from my $profile:

I think the PS parser should be smart enough that double-parens are not required in the second example, but oh well.  Pretty simple overall, and super convenient.  Enjoy!

dir | select fullname, lastwritetime

FullName                   LastWriteTime       
--------                   -------------       
C:\Users\rberg\Contacts    2/19/2009 12:34:40 PM
C:\Users\rberg\Desktop     3/24/2009 12:49:31 PM
C:\Users\rberg\Documents   3/23/2009 4:34:23 PM
C:\Users\rberg\Downloads   3/25/2009 6:38:20 PM
C:\Users\rberg\Favorites   2/19/2009 12:34:43 PM
C:\Users\rberg\Links       3/10/2009 3:36:02 PM
C:\Users\rberg\Music       2/19/2009 1:26:36 PM
C:\Users\rberg\Pictures    2/19/2009 1:26:38 PM
C:\Users\rberg\Saved Games 2/19/2009 12:34:40 PM
C:\Users\rberg\Searches    2/19/2009 12:34:49 PM
C:\Users\rberg\Videos      2/19/2009 1:26:39 PM
C:\Users\rberg\.kdiff3rc   3/25/2009 5:23:33 PM
C:\Users\rberg\_lesshst    3/4/2009 3:01:33 PM 

It looks like it’s doing something useful, right?  But the more I use Powershell, the more it seems like it’s violating its own guidelines like “input & output should be useful objects, not text-based hacks” and “design for the middle of the pipeline.”  Let’s examine what Select-Object really returns. 

PS >dir .\foo.txt | select name | gm

   TypeName: Selected.System.IO.FileInfo

Name        MemberType   Definition                      
----        ----------   ----------                      
Equals      Method       System.Boolean Equals(Object obj)
GetHashCode Method       System.Int32 GetHashCode()      
GetType     Method       System.Type GetType()           
ToString    Method       System.String ToString()        
Name        NoteProperty System.String Name=foo.txt 

That’s not a Name, that’s something else entirely.  Besides, I get the feeling it’s not being completely honest with me…doesn’t a FileInfo object have more methods?…

PS >(dir .\foo.txt | select name).gettype()

IsPublic IsSerial Name               BaseType
-------- -------- ----               --------
True     False    PSCustomObject     System.Object 

Caught ya!  Liar! 

I wouldn’t mind a little custom magic going on under the hood if it meant more power in the user’s hands.  But in reality, these PSCustomObjects being tossed around seem to be of very little utility.  In almost every case, simply returning the native type (e.g. a System.String in the case of “select name”) would play nicer with the rest of the pipeline.  I understand there’s a tough barrier when you start selecting multiple objects, or when you want lazy evaluation -- but sorry guys, the current solution ain’t it.

To be clear, I want to be able to do stuff like:

$a = dir foo.txt | select lastwritetime
# oops, we don’t have a real DateTime
$b = $a.adddays(1)  

# oops, neither a string nor a ‘name’ property
dir *.exe | select basename | get-process 

# not even the NoteProperties work in a useful manner
dir | select psparentpath | convert-path

# wouldn’t this be cool?  PS already has quasi tuple syntax, after all
$x, $y = dir | select attributes, length

# or this?  assume do-something is a cmdlet that takes 3 strongly typed parameters by position
# and/or by property name
dir | select fullname –as path, versioninfo, isreadonly –as force | do-something

Am I crazy to want these to work?  Anyone know of ongoing work in this area before I waste some hobby time? :)

In the process, I’ve come across some people doing seriously amazing things with Powershell.  Some of these efforts I hope I can find time to contribute and extend; others I’ll just sit back in awe.  (I’m not saying which is which…you too will have to subscribe!)

• Bart de Smet
• Real LINQ cmdlets for Powershell – based on “lazy” expression tree builders, with the full range of operators, not just the few “greedy” *-Object functions PS comes with
• Autogenerating cmdlets that mirror an object's method calls
• Using Powershell's ETS to surface extension methods – reminds me of my add-types.ps1, but more broadly useful since it incorporates the design intent embedded in the extension methods’ type info rather than importing blindly
• Lance
• Executing SQL / Powershell statements from your iPhone – are you kidding me?!!
• James Brundage
• Exploring WPF routed events
• Cmdlets for maintaining your Recorded TV folder
• Josh Einstein
• Quick & dirty progress bars
• Quick & dirty menus

Happy scripting!

First, let’s look back at the legacy tf.exe command line.  In the effort to be both user friendly and flexible, its behavior has actually become quite complicated.  As of TFS 2008, the logic appears to be evaluated in this order of precedence:

1. If the /prompt flag is present for this command, always use Prompt mode, otherwise
2. If the /noprompt flag is present for this command, always use Noprompt mode, otherwise
3. If the tf.exe process’ stdout stream is redirected, use Noprompt mode (unless the environment variable TFS_IGNORESTDOUTREDIRECT is set), otherwise
4. If executing in script mode with a @command file, use Noprompt mode (unless the most recent invocation of the setnoprompt command was “setnoprompt false”), otherwise
5. Default to Prompt mode

Yikes.  I’d actually forgotten just how many variables there were until I started running tests for this blog post.  Suffice to say, the Powershell cmdlets approach things in a much simpler way:

1. If the –prompt switch is present for this cmdlet, always use Prompt mode, otherwise
2. Default to Noprompt mode

Simple enough.  I know a lot of power users will rejoice at this, having long since resigned themselves to /i muscle memory lest random WinForms interrupt their console workflow.  However, there are ramifications to this behavior that you should be aware of.  “Prompt mode” means more than simply popping up dialogs.  First of all, there are some UI features that are still not accessible in Prompt mode without additional parameters, such as tf diff /configure.  More importantly, leaving Prompt mode turns off a number of safeguards:

• Undo will permanently discard your local changes.  (I think TFS should use the Recycle Bin, but that’s another show…)
• Shelve /delete will permanently delete shelvesets.  (The server used to keep them around until a cleanup job ran, but again that’s the way things work now.)
• Destroy, well, destroys.

These aren’t the only examples; you get the idea.  None of this behavior is new to TFS in general, but with the default settings of the Powershell tool, it’s a lot easier to shoot yourself in the foot.  Even good old Checkin is likely to surprise you the first time you see it simply go without any further interaction.  [a “no blank comments” checkin policy might help here, nudge nudge] 

So have fun, just be careful.  If you’re using the power tools then you are ready to be a power user, right? :)

Like everyone else, I wish the TFS team had supported x64 much earlier on.  You can see in Microsoft.TeamFoundation.Common.dll that while there are a decent number of routines under the NativeMethods static class that need to be ported, it’s not an enormous task.  Turns out that supporting setup and deployment on x64 servers (with all the requisite expansion of the test matrix, etc.) is by far the higher cost.  Good news is that x64 is supposed to be on the Rosario feature list.

In the meantime, I can’t have John Robbins’ impression of our power tool be negative!  I consider my trip to attend his “Native Windows Debugging” class one of the highlights of my MS career.  As a TFS power user I frequently live in x86 shells, so here’s a tidbit from my $profile that helps keep me sane:

$isX86Process = ( $env:Processor_Architecture -eq "x86" )

...

$Global:PscxHostTitlePreference = { $(if ($IsAdmin) { "Admin: " }) +
                                    $PscxWindowTitlePrefix +
                                    $(get-location).Path +
                                    $(if ($IsX86Process) {" (x86)"})
                                  }

Naturally, I like Vivek’s auto-Fork example too – may need to incorporate somewhere into my library of stuff…

Unfortunately, this syntax is not supported.  (Neither is the /workspace parameter, in case you were wondering.)  It’s an oversight I hope will be corrected in the future.  Until then, here’s a quick fix:

tf view $/project/file.txt > temp.txt
tf diff c:\file.txt temp.txt
del temp.txt

This technique should be easy to put into your scripting language of choice.

However, there are some key differences:

• ConvertTo-FixedByte lets you specify any width between 6 and 22, while Format-Byte is fixed at 10 characters.
• ConvertTo-FixedByte allows the entire UInt64 range (~10^20), while Format-Byte only goes up to TB (~10^15).
• ConvertTo-FixedByte does not allow pipeline input, while Format-Byte does.
• ConvertTo-FixedByte uses the SI standard prefixes, as recommended by IEC, IEEE, EU, and NIST.  Format-Byte uses binary-based prefixes (although it does not display them as KiB, MiB, etc).
  PS> convertto-fixedbyte 2000 -width 10
        2 KB
  PS> format-byte 2000
    1.953 KB
• ConvertTo-FixedByte uses the biggest possible unit so long as the value is at least one unit.  Format-Byte waits until you’ve exceeded 2^n to use the next biggest unit.
  PS> convertto-fixedbyte 1000 -width 10
        1 KB
  PS> format-byte 1024
     1024 B
• Both cmdlets attempt to output a fixed width by rounding, but Format-Byte’s approach fails to handle some edge cases correctly:
  PS> convertto-fixedbyte (1000*999) -width 10
      999 KB
  PS> convertto-fixedbyte (1000*999+1) -width 10
  999.001 KB
  PS> convertto-fixedbyte (1000*999+499) -width 10
  999.499 KB
  PS> convertto-fixedbyte (1000*999+500) -width 10
        1 MB
  PS> convertto-fixedbyte (1000*999+501) -width 10
        1 MB
  PS> convertto-fixedbyte (1000*1000-1) -width 10
        1 MB
  PS> convertto-fixedbyte (1000*1000) -width 10
        1 MB
  PS> convertto-fixedbyte (1000*1000+1) -width 10
        1 MB
  PS> format-byte (1024*1023)
     1023 KB
  PS> format-byte (1024*1023+1)
  1023.001 KB
  PS> format-byte (1024*1023+511)
  1023.499 KB
  PS> format-byte (1024*1023+512)
  1023.5 KB
  PS> format-byte (1024*1023+513)
  1023.501 KB
  PS> format-byte (1024*1024-1)
  1023.999 KB
  PS> format-byte (1024*1024)
     1024 KB
  PS> format-byte (1024*1024+1)
        1 MB
• Both cmdlets omit trailing 0’s, instead padding the front with extra spaces.  [thought there was a slight difference here, but now I can’t repro it!]
• And of course: PSCX is open-source, while the Power Tools are not.  So I can’t read the PSCX source and Keith can’t read mine.  Even so, I hope some of the ideas can cross-pollinate :)

<View>
  <Name>Item</Name>
  <ViewSelectedBy>
    <TypeName>Microsoft.TeamFoundation.VersionControl.Client.Item</TypeName>
  </ViewSelectedBy>
  <TableControl>
    <TableHeaders>
      <TableColumnHeader>
        <Width>7</Width>
        <Alignment>Right</Alignment>
      </TableColumnHeader>
      <TableColumnHeader>
        <Label>CheckinDate</Label>
        <Width>10</Width>
        <Alignment>Right</Alignment>
      </TableColumnHeader>
      <TableColumnHeader>
        <Label>ContentLength</Label>
        <Width>7</Width>
        <Alignment>Right</Alignment>
      </TableColumnHeader>
      <TableColumnHeader>
        <Label>ServerItem</Label>
        <Alignment>Left</Alignment>
      </TableColumnHeader>
    </TableHeaders>
    <TableRowEntries>
      <TableRowEntry>
        <TableColumnItems>
          <TableColumnItem>
            <PropertyName>ChangesetId</PropertyName>
          </TableColumnItem>
          <TableColumnItem>
            <ScriptBlock>$_.CheckinDate.ToString('d')</ScriptBlock>
          </TableColumnItem>
          <TableColumnItem>
            <ScriptBlock>
              if ($_.ItemType -eq [Microsoft.TeamFoundation.VersionControl.Client.ItemType]::Folder)
              { '&lt;DIR&gt;' }
              else
              { ConvertTo-FixedByte $_.ContentLength 7 }
            </ScriptBlock>
          </TableColumnItem>
          <TableColumnItem>
            <ScriptBlock>
              ConvertTo-FixedPath $_.ServerItem 7,10,6
            </ScriptBlock>
          </TableColumnItem>
        </TableColumnItems>
      </TableRowEntry>
    </TableRowEntries>
  </TableControl>
</View>

And a few examples of what it looks like, taken from an 80- and a 112-character-wide console:

PS> tfdir 

Changes CheckinDat Content ServerItem
   etId          e  Length
------- ---------- ------- ----------
   8224  2/25/2009   <DIR> $/Test-ConchangoV2/super/u...g/directorynamefromhell
   8224  2/25/2009   11 KB $/Test-ConchangoV2/super/u...efromhell/devilsurf.jpg
   8224  2/25/2009   12 B  $/Test-ConchangoV2/super/u...orynamefromhell/foo.txt
   8224  2/25/2009    5 MB $/Test-ConchangoV2/super/u.../PowerGUI.1.6.1.639.msi

PS> tfdir 

Changes CheckinDat Content ServerItem
   etId          e  Length
------- ---------- ------- ----------
   8224  2/25/2009   <DIR> $/Test-ConchangoV2/super/ultra/very/very/mega/long/directorynamefromhell
   8224  2/25/2009   11 KB $/Test-ConchangoV2/super/ultra/very/very/m...ong/directorynamefromhell/devilsurf.jpg
   8224  2/25/2009   12 B  $/Test-ConchangoV2/super/ultra/very/very/mega/long/directorynamefromhell/foo.txt
   8224  2/25/2009    5 MB $/Test-ConchangoV2/super/ultra/very/very/m...torynamefromhell/PowerGUI.1.6.1.639.msi

You can see that the Powershell team’s “expand toward the right to minimize visual variance” concept is used to great effect.  However, we violated their “never provide a label” maxim in 3 out of 4 columns.  Oops!  Seriously though, I don’t think anyone would want to use a ScriptProperty with the exact parameters found in the formatter XML.  What we provided instead is far more useful: a couple of fully generic cmdlets named ConvertTo-FixedByte and ConvertTo-FixedPath.  I’ll cover the former in another post; there’s a fair amount of detail to dig into, but its use here is rather mundane. 

ConvertTo-FixedPath is what really makes this example shine.  If you’re like me, you hate managing long paths in shell environments.  Wrapping onto multiple lines, truncating the front, and (especially) truncating the end of the path are all unacceptable.  Cmdlets to the rescue!  This one has two modes (“parameter sets” in PS-speak).  The first is obvious enough:

PS> convertto-fixedpath 12345678901234567890 -width 16

12345678...67890

The 20-character input string is truncated to 16, but only by omitting things in the middle.  (Note that this mode has an off-by-one bug.  Hint: odd numbers.)  This allows you to answer the important questions: what is the file name? what branch/workspace are they located in?  Usually we don’t care as much about the intermediate directories.  Maybe the same is true for other kinds of strings too – let me know if you find it useful!

The other mode is designed explicitly for use in a ps1xml formatter.  Consider:

PS> convertto-fixedpath 12345678901234567890 -otherwidths 30, 20, 10

12345678...67890

Same output, but what the heck are the “other widths”?  Imagine this string were going into a variable-length field.  We want the string to expand dynamically, showing us as much of the filename as possible.  Yet if it does need to be cropped, we want it done intelligently, as if we’d known the width in advance and passed it as a –width parameter.

As it turns out, we can know the final width, given a little hackery.  The Powershell API lets you access the raw console host details, including its BufferSize.  All you need to do is subtract the widths of the other columns, plus room for the separator character PS places between each column.  So imagine the code above is used in a four-column formatter: 80 - 30 - 20 - 10 - (4*1) = 16.  Sure enough, if you scroll back up to the XML, you’ll see the values passed to –otherwidths are no coincidence.  We hand-tweaked every column width so it fit the data type as closely as possible without wrapping*, then plugged in those widths to the convertto-fixedpath cmdlet driving the final variable-length column.

This hack may not always work as Powershell migrates away from the ancient CSRSS hosting environment.  But in theory, anyone who implements PSHostRawUserInterface should be compatible.  It works in the Powershell v2 ISE environment that ships with Win7, for instance.  Custom-PS-tool-lovers, let me know how it goes.

*Except for column titles, obviously.  They were a necessary casualty of two higher-priority design considerations (a) keeping labels identical to the underlying property name (b) supporting the default 80-character console width without squishing average-sized paths.

function find-orphan {
  param([string]$proj = $(throw 'ssmssqlproj file is required'))

  $proj = resolve-path $proj
  $dir = split-path $proj

  $xml = [xml](cat $proj)
  $files_from_proj = ($xml.SqlWorkbenchSqlProject.Items.LogicalFolder |
    where { $_.name -eq "Queries" }).items.filenode |
    foreach { join-path $dir $_.name } |
    sort

  $files_from_dir = ls $dir -r -filter *.sql |
    foreach { $_.fullname } |
    sort

  compare $files_from_proj $files_from_dir
}

Unfortunately, the standard answer from the product team didn’t work for me. 

<FIELD type="Integer" name="AreaID" refname="System.AreaId">
  <HELPTEXT>AreaID</HELPTEXT>
</FIELD>
<FIELD type="Integer" name="IterationID" refname="System.IterationId">
  <HELPTEXT>IterationID</HELPTEXT>
</FIELD>
<FIELD type="String" name="Product Area - Validation" refname="Coatue.ProductAreaValidation">
  <HELPTEXT>Hidden field used to validate Product Area</HELPTEXT>
  <WHEN field="System.AreaId" value="84">
    <COPY from="value" value="Restricted" />
  </WHEN>
  <PROHIBITEDVALUES>
    <LISTITEM value="Restricted" />
  </PROHIBITEDVALUES>
</FIELD>
<FIELD type="String" name="Sprint or Release - Validation" refname="Coatue.SprintPathValidation">
  <HELPTEXT>Hidden field used to validate Sprint or Release</HELPTEXT>
  <WHEN field="System.IterationId" value="84">
    <COPY from="value" value="Restricted" />
  </WHEN>
  <PROHIBITEDVALUES>
    <LISTITEM value="Restricted" />
  </PROHIBITEDVALUES>
</FIELD>

It successfully blocked work items that had Area/Iteration paths I didn’t want, but I’d continue to get validation errors after I changed the paths in the form to something else.

At this point I started to wonder whether the AreaId and AreaPath fields were as intricately tied as I thought they were.  After all, I didn’t have any rules saying to update one when the other changed.  (The documentation kinda implies this but doesn’t spell out the mechanism.)  So I decided to test at the object model level: Get-TfsServer OM wrapper to the rescue!

PS C:\Users\rberg> $tfs = get-tfsserver njtfs –all
PS C:\Users\rberg> $bug = $tfs.wit.GetWorkItem(1333)
PS C:\Users\rberg> $bug.AreaId; $bug.IterationId
84
84  

PS C:\workspaces\ws1> $bug.AreaPath; $bug.IterationPath
Test-ConchangoV2\test
Test-ConchangoV2\Release 1\Sprint 4

PS C:\Users\rberg> $bug.fields | where { $_.name.contains("Validation") } | select value
Value
-----
Restricted Restricted                                                                                                                       

PS C:\Users\rberg> $bug.AreaId = 104; $bug.IterationId = 91
PS C:\workspaces\ws1> $bug.AreaPath; $bug.IterationPath
Test-ConchangoV2\test
Test-ConchangoV2\Release 1\Sprint 4 

PS C:\Users\rberg> $bug.fields | where { $_.name.contains("Validation") } | select value
Value
-----
Restricted
Restricted

Nope, not a synchronization issue between path on the form <–> underlying ID.  Looks like I really do need to tweak Gregg’s advice.  All you need is a corresponding WHENNOT rule to cancel out each WHEN rule as it’s no longer needed.  Here’s what the hidden validator for Area looks like now:

<FIELD type="String" name="Product Area - Validation" refname="Coatue.ProductAreaValidation">
  <HELPTEXT>Hidden field used to validate Product Area</HELPTEXT>
  <WHEN field="System.AreaId" value="84">
    <COPY from="value" value="Restricted" />
  </WHEN>
  <WHENNOT field="System.AreaId" value="84">
    <COPY from="value" value="Ok" />
  </WHENNOT>
  <PROHIBITEDVALUES>
    <LISTITEM value="Restricted" />
  </PROHIBITEDVALUES>
</FIELD>

Being relatively new to WIT customization, the answer wasn’t immediately obvious.  TFS doesn’t let you stick an ALLOWEDVALUES rule on fields like System.CreatedDate that the system populates on creation.  And anything you stick on a user-editable field will inevitably block users from navigating an existing work item through the rest of its legitimate workflow.  The path I took was modifying the initial transition from “”.  XML excerpt:

        <TRANSITION from="" to="Active">
          <REASONS>
            <REASON value="Build Failure" />
            <DEFAULTREASON value="New" />
          </REASONS>
          <FIELDS>
            <FIELD refname="Microsoft.VSTS.Common.ActivatedBy">
              <COPY from="currentuser" />
              <VALIDUSER />
              <REQUIRED />
            </FIELD>
            <FIELD refname="Microsoft.VSTS.Common.ActivatedDate">
              <SERVERDEFAULT from="clock" />
            </FIELD>
            <FIELD refname="System.AssignedTo">
              <DEFAULT from="currentuser" />
            </FIELD>
            <FIELD refname="System.Title">
              <ALLOWEDVALUES>
                <LISTITEM value="Before 2009-02-12" />
              </ALLOWEDVALUES>
            </FIELD>
          </FIELDS>
        </TRANSITION>

Most of this comes from the stock MSF Agile v4.2 template; the System.Title field with the strange rule toward the end is my addition.  Doesn’t really matter what you put in the value, so long as you don’t tell your users what it is :)

The arrival of the Fall 2008 Powertools hinted at yet another possibility based on Powershell.  Script-friendly unlocking is particularly enticing for scenarios like the one I found myself in last week: transitioning a team from exclusive checkouts to an edit-merge-commit workflow.  Turning off the exclusive settings on the Team Project is the obvious first step, but what to do about the hundreds of existing pending changes?  I can’t ask everyone to suddenly checkin their work (which may be far from ready to share, or even build), but I also can’t reorganize the tree unless every lock is removed.  Thus:

del temp.hat 2> $null
foreach ($pendingSet in get-tfspendingchange -user *)
{
    $workspace = '"' + $pendingSet.Name + '";' + $pendingSet.OwnerName
    $pendingSet.PendingChanges | where {$_.IsLock} | foreach {
      $item = '"' + $_.ServerItem + '"'
      "lock /lock:none /workspace:$workspace $item" | out-file temp.hat -append
    }
}
tf "@temp.hat"
del temp.hat

This isn’t the cleanest solution in the world.  You couldn’t just wire up the “find all locks in the system” example I provided for Brian’s post to a Remove-TfsLock cmdlet -- even if the Power Tools provided one (which they don’t yet).  By convention, a pipeline of TFS cmdlets transmits QualifiedItems, but to unlock an arbitrary item we need two additional pieces of information from the PendingSet object.  So we fall back on good old procedural loops around tf lock.

Could we improve the script?  Sure.  We could batch ~12 items at a time* for a better performance, though the gain is not nearly as big as using a @hatfile in the first place.  We could also be a little more robust.  Get-TfsPendingChange returns a full PendingSet in the general case, but sometimes the return type decays to a simple PendingChange[].  If our query returns exactly 1 workspace, then our logic for populating $workspace won’t work. 

Of course, we could also do a lot worse!  I originally tried to add the wrapper quotes in-place, but quickly got into syntax trouble.  After consulting the relevant Powershell blog post I eventually got it right, but it was an unreadable mess.  For example, line 4 read:

$workspace = "`"$($pendingSet.Name)`";$($pendingSet.OwnerName)"

Yuck.

*3200 character limit on each line of a tf.exe script file; TFS paths are 260 chars max