Thursday, 18 March 2010

Post build events using ROBOCOPY instead of XCOPY

I don't know about you, but for a long time I have used XCOPY statements in my Visual Studio post build events to copy my Umbraco files from the project folders to the local version of the website associated with the project.

For the last few months we have been building a website framework for a client, who has subsequently sold the site to 5 clients, each with a different skin and some variations in their functional requirements.

So, we now have a single source solutions, that builds and copies the site files into 5 seperate local websites, which enables us to easily test them all, what we had found was that this process was starting to slow up our build process and was reaching 30-45 seconds on a high spec Quad core machine (and slower on others)

Today I asked Colin to create seperate Solution Configurations within Visual Studio so that while we were developing we could target a single site, and when we wanted to test all sites, we could target "ALL" and the Post Build script would then copy the files to all sites.

This worked well, and with a couple of other optimisations, our build was now taking about 10 seconds for a single site.

Then Colin came across ROBOCOPY and suggested that maybe this would be a suitable alternative to XCOPY, well, I had not heard of it.. (shock horror some of you shout, some I am sure like me, are also wondering what it is!)

ROBOCOPY is new in Windows Vista & Windows 7 (you can also download it for XP & Windows 2003) and it has a lot of additional features, the two that were most interesting to us were:

/MIR = Mirror a folder tree
/XD = Exclude Directories
/NP = No Progress (i.e. it does not give you a chart of it's results, which just fills up your Output window!)

So, we set about implementing ROBOCOPY, we decided to use the /MIR switch on all folders that we knew were always stored in our project folders:

- images
- css
- masterpages
- xslt

And for other files we just used the straight robocopy functionality.

We also decided to exclude all the .SVN directories using the /XD switch and finally we added the /NP switch as mentioned above.

The beauty of all of this, is the /MIR functionality, as this means that only files that have changed will be copied across which greatly speeds up the process, especially on the images folders which previously copied across on every build, now, if we add a new image to the project it will be copied across automatically and then never again, unless we change it of course!

The build time now for all sites is approximately 4 seconds and for a single site, 2 seconds, I would highly recommend the time to make the same optimisations to your build processes if you have not done so already.


  1. Yup Robocopy sure is great.

    We use it on post commit events form SVN to copy files around. However we are now moving over to MSBuild (You can still call Robocopy from MSBuild or use the built in copy commands - which also support just copying changed files).

    You could also have just added the /d switch to your xcopy command. This will only copy files that are newer than the destination file


  2. Nice, was looking for a solution to track changes in css and images folder for a front-end dev. The /mon function seems to do the job.



  3. The main reason we actually looked for an alternative to using XCOPY was that you cannot have spaces in Directory Names in the Exclude file, if you wish to prevent certain folders from being copied (this is a known bug with XCOPY)



  4. You're just in time, I've been thinking about a setup to update multiple sites that will use the same codebase. However, I really don't want to do that with every single build that I do.

    2-4 seconds is very acceptable to me though, sounds good. I think though that in time, you'll find that you might want to have some more control over the different sites.
    Tim has already mentioned MSBuild and I'd like to recommend episode 145 & 158 of DotNetRocks TV, all about MSBuild. I am very impressed with what it can do and it will likely solve a lot of issues for me with regards to continuous integration, looking forward to play with it.

    For now, I will probably just go for robocopy, but MSBuild has my full attention.

  5. Hi Sebastiaan,

    I've used and nAnt before with a complete build process, including test automation etc.

    We are actually looking at setting up either Cruise Control or TeamCity which looks like a nice (but not free) alternative.

    The main reason for doing this is that our current automated deployment can only deploy to three servers, and we are soon going to be supporting a fourth site with the same code base, so time to update our deployment process!

    We will also be looking into either using MSBuild or nAnt for the build scripting, the important thing is that it's fast for a developer and that the same build scripts are run on the build/integration server.

    Currently the majority of our projects are lacking any automated testing, but this is definitely something I intend to change over the next couple of months, but as always, for some sites the current solution we are using will be perfectly adequate :)


Top 5 most popular posts