One of the small costs of transparency | Howard Dierking


: 3

If you’ve been following, you’ll notice that we’ve had a flurry of activity over the last couple of weeks, culminating in the release of Web API preview 5.  If you’ve been following our Codeplex repository for a while, you’ll also note that this flurry of activity was preceded by months of inactivity.  This wasn’t because we were just sitting around talking waiting for the code to update itself.  We had been wanting to update the repo for a while.  The problem was that the process to update the code was very hard and very manual (meaning it was also very error prone).  This is largely due to the fact that our source code is completely self-contained in its repository.  Usually, you would think of self-containment as a good thing.  However, in the scenario where you want to be able to share your code with others (like on Codeplex, for example), this property becomes a major problem.  This is because code in our repository takes 0 dependencies on anything outside of our repository – including things like .NET Framework assemblies.  Additionally, our build files contain all sorts of includes to custom tools, custom build targets/properties, etc.  As a result, getting code out of our repository and then updating it so that it will actually build is a non-trivial task – until now.

I went through this manual process once and quickly decided that I would never do that again.  I already had an interest in PowerShell, so decided to kill multiple birds with one stone and automate the process using PowerShell.  Additionally, because one of the major steps in the automation workflow is transforming the project files to remove internal assembly and tool references, I called into some XSLT from my PowerShell script.

At a high level, the workflow looks as follows:

  1. Sync our product code from our internal repository
  2. Build our product code (this will generate needed files that rely on internal build tools)
  3. Create a new clone of the Codeplex repository
  4. In the Codeplex clone, delete everything in the source and test folders (this will better help to identify delete files in the hg repo when committing)
  5. Copy all source and test files from our internal repo to our hg clone
  6. Run XSLT over all *.csproj files in the hg repository to remove all internal references
  7. Run RegEx over all AssemblyInfo.cs files to remove delay signed info from InternalsVisibleTo attributes
  8. Run RegEx to clean up some assembly strong name references in some test config files
  9. Open the solution in Visual Studio and make sure that all projects build and that all tests run

As you can see, there are a few things going on here – even with the automation – so imagine what the manual process looked like. 

Like I mentioned earlier, this automation project gave me an excuse to do something that I had been wanting to do anyway – learn PowerShell.  As such, I want to show you the PowerShell script in part because you may currently (or one day) be facing a similar challenge, and in (larger) part because I want your feedback on how I can improve the PowerShell (like I said, I was learning).

Anyways, here’s the PowerShell:

Additionally, a big part of the workflow is transforming project files to remove any dependencies on internal libraries and tools.  For this workflow task, XSLT was the right fit – and that XSLT looks like this:

I hope that this proves helpful if you ever find yourself in the position where you have to regularly keep code in sync between 2 different repositories (or even the same repositories with different folder structures).  And like I said, I welcome feedback on how I can improve my PowerShell.