deployment

How to extract only changed files from SubVersion for partial deployment using TortoiseSVN

Matt Simner SubVersion , ,

I was really surprised how long it took me to find out how to do this – as it’s quite a simple operation, but if your deployment folder structure matches your SVN repository (e.g. classic ASP site, PHP etc) and you want to do a partial deployment of only files changed in a particular revision (or revisions) then here’s how to get the files (complete with folder structure) using TortoiseSVN:



  1. First you need to work out how you’re going to identify your revision range.  There’s a number of ways to go about this:


    1. Version comments are your friend

    2. You could just note the revision number when you commit.

    3. You could use tags to help identify the range.  I use CruiseControl.NET and so all ‘builds’ are automatically tagged.  If you always release from tags then you can just ‘show log’ on the tag and see the max revision number. 

    4. You could just use a date range.

  2. Once you’ve decided ‘how’ you’re going to identify the revisions (it may be as simple as the ‘last commit’) then either through your working copy, or from Repo Browser ‘show log’ on the root of your ‘deployment’ folder structure.  The files you’re interested in may be within a ‘code’ or ‘source’ folder or similar so you only want to get the files you want to deploy. 

  3. Select the revision/s based on the method you’re using (step 1) and do ‘Compare revisions’.  If you’re just looking at one revision then do ‘Compare with previous revision’.

  4. Review the list of files and select all (assuming the list looks correct) then right-click and ‘Export selection to…’

  5. The file structure will be created at the folder you specify, and you can then zip or do whatever you normally do to deploy.

If you only want the list of files then you can choose ‘Save list of selected files to…’ (text file).


This is all cool and simple, but it’s still quite a manual process.  If you’re certain of the revisions or you automatically keep track of the last deployment revision then it would probably make sense to automate this further with something like NAnt (which is what I’ll attempt to eventually get round to). 


This process also doesn’t cater for deletions (as such), so special care needs to be taken when reviewing the list of files (the action column shows the nature of the changes).

Getting the most out of ASP.NET Web Deployment Projects

Matt Simner ASP.NET, Setup and Deployment, Tools, Visual Studio , , , ,

In my ongoing love (but mostly) hate relationship with ASP.NET Web ‘Site’s’ I’ve been using Web Deployment projects to make things more bearable. 


I currently swap in connection strings from 3 files – one for each build configuration (debug, test, release – connectionstrings.debug.config etc ).  This works fine as per the doco on WDP.  I use CruiseControl.NET and NAnt to automate builds, and a few nagging ‘automated’ pieces were missing from the puzzle. 



  1. Encryption of connectionStrings (or other web.config sections that you want to protect) – without affecting the ‘source’ file.  I’ve assumed here that ‘internal’ people are trusted. 
  2. Changing of other config stuff (like debug=false) in the test and release builds.  (My attempts to get this to work had previously failed as you don’t seem to be able to specify system.web as a replaceable section.
  3. Encrypting Forms authentication passwords, using MD5 hash.  This isn’t difficult, I just didn’t have a tool to generate the hash value.

Encryption of config sections


OK – after re-reading Scott Gu’s post on Web Deployment Projects, and K. Scott Allen’s post on how to simply encrypt sections of config files, I realised that I could just add a post-build event (manually) in the wdproj file (right-click in solution explorer –> open project file). 


The build events are already in but commented at the bottom of the file.  I ended up with

<Target Name=”AfterBuild”>
<Exec WorkingDirectory=”$(OutputPath)” 
      Command=”C:\windows\Microsoft.NET\Framework\v2.0.50727\aspnet_regiis -pef connectionStrings .” />
<!– Also remove our ‘source’ config files using the del command rather than the delete task as you 
have to jump through hoops to specify wildcards –>
<Exec WorkingDirectory=”$(OutputPath)” Command=”del compilation*.config” />
<Exec WorkingDirectory=”$(OutputPath)” Command=”del connectionstrings*.config” />
</Target>

If I put this anywhere other than ‘AfterBuild’ it didn’t seem to do anything.  I certainly learnt a bit more about aspnet_regiis, as I’d only used it previously to ‘install’ ASP.NET.  I also had to specify the path to aspnet_regiis, but you could obviously use a property for this (I’m new to MSBuild – only dipping in when I have to, so the framework path may already be a standard property?).


Replacement of system.web sections


The key thing here (which I don’t believe was documented very well anywhere) is how to replace system.web elements.  Other typical replacements – e.g. appSettings or connectionStrings are children of the root config element.  You’d therefore assume that you need to replace the whole of system.web (which is a little inconvenient – but still worth it).  This doesn’t work and you’ll get a ‘nice’ WDP00002 error saying it can’t find the system.web element (a bit like saying ‘can’t find printer’ when it’s right next to the computer!). 


You just have to go one level down as follows (in the Deployment –> Web.config file section replacements property page):


system.web/compilation=compilation.release.config


compilation.release.config may be as simple as…

<compilation debug=”false”></compilation>

You might have a warning saying ‘compilation’ isn’t a valid element, but this is just the intellisense barking as it validates against the config schema.


Encrypting Forms Authentication Passwords


This is pretty simple and there’s lots of docs to support this, but I wanted a simple tool to generate the hash for a given string, and a quick google yielded a nice little command-line tool…


This way you can plug it into your build if you need to, but also replace for different environments using the techniques above.