This project is read-only.

Powershell Scripts in Git - store in shared location?

Nov 16, 2013 at 1:24 PM
just trying to configure the Pre/Post Build Powershell scripts (ApplyVersionToAssemblies.ps1) within the Build process.
I'm using GIT for my project. It seems that i have to place the Powershell scripts within my project and not at a single shared location.
If i need to replace the scripts, i would have to touch every single project and replace the build powershell scripts instead of changing it centrally. I can't believe this is the case.

Is there a way to place the scripts centrally?

Thx, Peter
Feb 9, 2014 at 7:37 PM
No I don't think there is. Did you come to the same conclusion?

Feb 10, 2014 at 8:56 AM
Hi Mike,

yes, it seems there is no other solution at the moment. Maybe its worth to address it to MS.

Feb 19, 2014 at 8:45 AM
Edited Feb 19, 2014 at 8:46 AM
Hi Peter,
I'm facing a similar problem and I've solved it with this solution, at the moment:
  • Create a git repo within your team project (called, for example BuildUtilities), to store all the tools needed by builds: powershell scripts, custom build templates and of course TFSBuildextensions assemblies... :-)
  • Modify the standard build template for git, adding a pull activity from BuildUtilities repo, before the default pull activity.
In order for this to work you have to make a couple of customizations to the build template, though:
  1. modify the working directory where the BuildTools files are pulled, so that they won't be overwritten by the pull of your source code
    I've set the workingFolder so that the directory structure on the build machine is like:
    -- BuildDirectory
    ------- BuildTools (the scripts and utilities you will need during the build)
    ------- src (the source code you will build)
  2. reset the SourceGetVersion property of the BuildDetail object to "T" (tip), just after the first pull, because otherwise you will get an error like "No valid git object identified by '..blah blah blah..' exists in the repository".
    This happens because the pull activity, sets the SourceGetVersion property to the commit ID of the pull, so the following pull will try to get the source from another repo at the same commit ID, that of course does not exist...
Hope this helps.

Marked as answer by mikeFourie on 3/1/2014 at 11:17 AM