PowerShell Join-Path with multiple parameters

In my day to day job I use a fair amount of PowerShell. Some might say the deployment process is mountains of PowerShell glued together by Team Foundation Server. Cruel but accurate. I don’t make any claims to be a PowerShell expert (I really don’t) so I post this not to show my PS brilliance but rather as a way for me to practice and learn. I appreciate this has been written about elsewhere but as I say it’s just practice and I wrote this without peeking at anybody else’s solution (promise)

Standard Call

Within the mountains of PowerShell I use Join-Path quite a bit. It’s fine for two parameters


But I’m always mildly surprised it can’t cope with more parameters


Boom – unhappy code, unhappy coder.

Piped Call

The most straightforward solution is to pipe the output of one call to a send call and so on. So

Sadly doesn’t work

In order to get this to work the second parameter needs to be explicitly named

Which then works perfectly well

Using parameter array

It feels as if it should/must/ought to be possible to do this without piping – by passing in an array of parameters. Indeed it is. This function will do the trick

To call it it needs to be imported into the shell, There are a number of ways to do this but the easiest is by using the dot operator (dot-sourcing) i.e.

The function is then available to be called

And again works perfectly well

So there you have it, both original and insightful.  Sadly the original is not insightful and the insightful is not original. But I enjoyed writing it!

Note on script permissions

When importing the script about you may see this

scripts is disabled on this system. As part of Microsoft Trustworthy Computing initiative PowerShell is secure by default won’t allow scripts to be run. To bypass this run

This is just for demo purposes though. For production or anything other than quick demos then consider signing scripts (see links below).

Useful Links

Adding functions to Powershell sessions

Execution Policies

Better ways to work with the PowerShell execution policy

Conditional Deployment with WIX

Often when deploying an application you need guaranteed access to a certain area of the file system. This can change depending on the OS. The challenge is to produce an msi that can detect that and supply the correct values.

Summary of WIX

Wix is an xml based tool used to generate msi files. To use

  1. Create your WIX file – MyMsi.wxs
  2. Run the tool candle.exe to generate the wixobj file
  3. Run the light.exe tool to generate the msi

WIX has the advantages of being

  1. Free
  2. Complete – does everything that I have asked of it
  3. Fairly well documented
  4. Command line runnable so it can be easily integrated into continuous builds

It’s not all sweetness and light though. I find handcrafting the XML hard going and a bit obscure. Projects such as WixSharp and WixEdit can take the sting out of it. However when going past the basics it’s often easier to start to handcraft the XML.

The Problem

Often when deploying an application you want an area with guaranteed access to a certain area of the file system. The ProgramData folder fits the bill nicely. This folder is used for application data that is not user specific so it’s a good candidate as an area for downloads and so forth from an installed application. Unfortunately many of us need to support older OS such as XP which don’t have the ProgramData folder. In this instance a good candidate could be

We install our application using an msi generated by WIX.  What I really don’t want to do is maintain more than one wix source file (.wxs). Really, in my life I don’t want to maintain more than one of anything (DVD player, car, daughter etc…) and I really don’t want to maintain more than one wxs file. So there needs to be a way of

  1. Detecting the OS version in WIX
  2. Using that information to change a property within the wxs file

WIX is nothing if not complete so there is such a way.

Detecting OS version

The operating system is exposed by the Window Installer Property – VersionNT. So

  1. Windows 2000 is 500
  2. Windows XP is 501
  3. Windows Vista 600

And so forth as detailed here.

So to detect Windows XP you would need to include a condition element such as

Of course this blocks the install completely rather than changes a property so it’s only half the story.

Changing a Property Setting

To change a property conditionally on OS you need to reach for the SetPropertyElement. There are a few wrinkles with this

Action attribute

My first pass at this was

So you have a property. The two set property elements target the property element because of its common id. However if you run this then you get this error

So you need to deploy the Action attribute defined in the WIX documentation as

By default the action is “Set” + Id attribute’s value. This optional attribute can override the action name in the case where multiple SetProperty elements target the same Id (probably with mutually exclusive conditions).

So the wix elements become

Which gets over that issue

Before and After Attributes

Unfortunately making the installer with the revised XML generates this error

Which has the merit of being straightforward. It needs to know when in the install sequence the property should be set. The windows installer has a sequence of standard actions detailed here for example

  • InstallFiles
  • InstallExecute
  • InstallFinalise

And many others. (To me) it makes sense to set the property just before the files installs so …

And the WIX XML now becomes

Equally the After attribute can be used to set the properties after the InstallFiles install action.

SequenceType Attributes

Now when we make the WIX file we now get a more cryptic error

It turns out that there are 2 install sequences

  1. UI
  2. Execute

Looking again at this standard action table you can see there are two sections

  1. Wizard Dialog Stage (UI)
  2. Install Execution Stage (Execute)

The InstallFiles installer action only exists on the execute sequence and the WIX compiler needs to know that. So you now reach for the Sequence attribute and the WIX XML becomes

It now compiles and creates an msi that behaves differently on XP and later versions of windows. Job done!!


Once you have the flexible property it can be used to redirect output to a different location or used as a source for a config file transform such as

Which can be very useful.

So well done if you read this far. All the documentation exists on the internet but I found it puzzling so I hope this might help in a general demystification effort.

Useful links

About the ProgramData folder

WIX documentation

Windows Installer Operating System Property Values

Windows Installer Standard Actions

A C# API for WIX. Good for generating a base XML file to start with. Not complete though so will need to fall back to direct XML editing for more advanced scernarios

A simple UI for the XML file. Useful.

Deleting from Team Foundation Server

It’s non-obvious how to delete items from Team Foundation Server. Things can be removed from the web interface or from team foundation explorer but they can lurk around still and bother you. It’s surprising difficult to delete. These are the ways that I’ve cleaned up after myself in Team Foundation Server 2013 and 2015.

Workitems – Bugs and Backlog Items

The straightforward way is just to set the status to removed.

Removing work item from TFS

But depending on how you construct your queries they’ve a habit of shining through again. To me, there is a difference between “a bug has been created and I had a bit of a think about it and I think it’s not relevant” to “I’ve just completely created the wrong thing and I want to get rid of it”. So if you never want to see the workitem again then it’s down to the command line


and it’s gone. Careful now – once it has gone then it’s gone forever.


On the face of it, it is straightforward to delete builds. Just go to team explorer find the build, right click and press delete.

Deleting build from TFS web UI

The problem with this is that the build still exists in some sense and is included when calculating build version number.


Build definition is

Visible in the advance tab of the build definition

Build Label

The build includes the build revision token (Rev:.r) which increments by 1 for every build

If we want to delete the send build then fine – go to the web UI and press delete. If the build is requeued we will get

The build label jumps to 2 missing out 1. The deleted build still exists and counts towards incrementing the build revision token. This might not be an issue. However if you use the build label to drive out the version of the application as we do then this can become a significant issue. Suddenly a version has been missed which could cause various shades of confusion, upset and terror.

To avoid the TFS related terror scenario then the build needs to be deleted AND destroyed. Once again jumping to the command line

To delete the build (i.e. the same as through team explorer)

Now destroy the build so it is completely gone


Now destroy the build so it is completely gone

Now when the build is deleted the build versions work as expected and the revision number is reused i.e.

Work Item History

Work Item History

This is trickier still, the situation where you put some errant information in a Bug or PBI and want to remove it. It could be innocuous as posting in the wrong bug post (which I have done many times). It could be as eye wateringly bad as three paragraphs of invective targeted at a colleague. Sadly the cmd line doesn’t expose a way to delete work item history.

The only way I know is to code against the TFS object model and delete from there. The object model isn’t that well documented but it’s not bad to code against. One for a future post perhaps,

A note on the command line

The command tools used here (TFSBuild and witadmin) along with other helpful tools such as tf.exe, are found in program files at

I would recommend putting this filepath on your PATH environmental variable if you find yourself doing much TFS admin. That way you won’t have to continually navigate to the program files folder. You’ll soon get sick if doing that if you have do delete something from TFS more than a few times.

Useful Links

A full list of build tokens for XAML based builds

Details of programming against TFS object model

Amending PATH variable on a windows machine