how do you want tfs-related powershell scripts delivered to you?

There's a bunch of TFS scripts/cmdlets that are on my todo list (many thanks to Keith Hill and others for sending me the requests) and I've been debating the right way to share these out.  Unfortunately "ClickOnce for a collection of scripts" isn't around yet (much like "ClickOnce for library dll's, as much as I think that's a huge need, too 🙂

In the past, I've just posted each script as its own blog post with the .ps1 file attached.  This was the most flexible, as people could pick and choose which scripts they did and didn't want, and each script had a nice post explaining what it did and how it did it, typically with some example output.

As the number of scripts (or cmdlets) rises, I'm starting to feel this isn't an effective mechanism any more, as it will be more and more hassle for people wanting to use the scripts to find and download each of them in turn to get them all (or at least the ones they want).  It also becomes more difficult to know about all of them (unless I put together an index page, but then that's more work for me).

So I've been leaning towards a zip file approach - I zip up all the scripts (get-tfs.ps1, get-workspace.ps1, watch-requests.ps1, tail-tfsactivitylog.ps1, check-tfspolicies.ps1, etc.) into a single zip file and just keep it updated as new scripts (and changes to existing scripts) happen.  The zip file may include a README discussing some typical scenarios, but each script should be sufficiently self-documenting (by way of its name and the comments in the script).  I have a little more flexibility in creating more of a hierarchy of scripts, as I don't mind 4 levels of script dependencies if the user was very likely to have extracted all of them into their path together.

Then, people can download the zip at whatever point in time and just extract it to some place in their path (I use %UserProfile%\Documents\bin on my Vista machine, but I expect others will likely have a specific scripts area in their path).

I'm still likely to make a separate blog post for each new script, and I'll just maintain an "article" for the zip file (so it'll live at a fixed url).

FWIW, I also considered having a GotDotNet/CodePlex/whatever site, but one of my primary goals is easy of getting the scripts into a usable state.  The more work (install X, compile Y, installutil Z, etc.) that the user has to do before they can use the scripts, the worse, IMHO, since they're less likely to bother (and more likely to hit problems).  Admittedly, having them in a versioned store would be nicer since I'd love to have a cvsweb/svnweb kind of approach where I could link to (syntax highlighted and color-coded!) diffs between versions of a particular script to explain something in a blog post.

Any strong feelings on the zip file approach?  Is there a different approach you'd like to see?  Try to keep in mind it needs to be relatively fast for me - I want to focus on the scripts and not too awfully much on the delivery 🙂

Comments (3)

  1. Anthony Borton says:

    Hi James,

    I am in favor of your ZIP file strategy. I think the convenience of having one download for all the latest scripts is the most compelling reason. Now that decision’s made, when can we expect some more of the ps1 goodness 🙂


  2. keith_hill says:

    James, if you are interested in contributing to the PowerShell Community Extensions project I would love to have you join.  I have just started two TF cmdlets Get-TFLabel and Get-TFPending.  They are pretty basic but I’m really wanting to get PoSH access to the TFVC object model to allow more slicing and dicing in PoSH.   Check it one of our later builds at:

    I think this would be a good place for this sort of functionality because we have been building a number of developer oriented cmdlets like Get-PEHeader, Test-Assembly, Test-Xml, Convert-Xml, Format-Hex, etc.

  3. Eric Jarvi on Congrats to Team Test!. Aaron Hallberg on Doing an incremental get in Team Build. …

Skip to main content