At that time I was proposing a post-building event triggering robocopy, which did the trick for that particular situation. Some time later I had access at my team to “CopySauce”, a software that keeps watching your code base for changes, deploying immediately after the change is detected. Interestingly, a couple weeks after that Sean Holmesby (author of CopySauce) commented on my post, suggesting his tool as an alternative for Robocopy.

One thing that I like with that approach is the file auto-deployment, because it very nicely mimics what was (in my opinion) the only advantage of that old strategy of having both your solution code and the sitecore webapp at the same place: avoiding IIS restarts when changing non-compiled files (JS, CSS, markup, etc). And better than Robocopy, this won’t even require a compilation to be triggered – files are transferred when you save it.

Sitecore Rocks – Folder Syncronization

The only issue I have with that is the obvious need to start CopySauce to have it acting. Since we are already using Sitecore Rocks for some development tasks, as soon as I knew about the existence of a native feature that is similar to CopySauce I decided to give it a chance. If you already have Sitecore Rocks installed in your Visual Studio then you have all you need to start working.

Setup of your solution

Configuring the folder synchronization on your solution is a bit different than CopySauce – instead of having a XML file Sitecore Rocks offers you some visual aids integrated to Visual Studio. Please check the official documentation for details on how to properly configure your project.

You can specify what folders in your solution to start syncronizing with the right click menu

Then select one of the two syncronization methods

Folder Synchronization – literally

One thing which in my opinion is a weak of this tool is that, as it own name states, it can only be used to keep folders synchronized. As a consequence, you cannot keep files at the root in sync between solution and the webapp, having to manually deploy these.

This would typically affect you web.config at least, so avoid placing things that frequently changes in your solution at the root folder of your Website project.

Only folders can be kept in sync

At the solutions I’ve tested these are the folders I had to keep in sync to start taking advantage of the tool

Performance

The tool also starts deploying your changes as soon as you save it, although I have noticed sometimes a certain delay, generally not bigger than 10 seconds tho, which is acceptable compared to a normal build.

1) Your solution, and code, is fully immersed in the Sitecore web site;
2) Your solution, and code, is outside of Sitecore’s web site and you use some post build process to deploy.

His post supports second option, which indeed has advantages over the first, however a huge drawback (specially for those without SSD) makes our life harder: due to the post build deployment, IIS is constantly forced to restart on every build you make.

In order to handle that issue I’ve invested some time looking for a better way to deploy. What if I copy only the modified changes instead of everything? Perhaps I could often skip the files that causes restarts, such as DLLs and config files…

Robocopy

My solution lied on robocopy, for advanced file copying. At your website project on Visual Studio, put this command at the Post-build event command line box:

robocopy “$(ProjectDir).” “C:\inetpub\wwwroot\YourProject\Website” /E /FFT /XO
exit 0

•  Parameters:
  • /E – Copies subdirectories;
  • /XO – Excludes older files – this is the trick, skipping old files;
  • /FFT – Assumes FAT file times (two-second precision) – this somehow interferes on how robocopy defines what is “older” to be copied;
  • exit 0 – If we don’t add this to the end of the script, our Continuos Integration server breaks because robocopy returns a code different than “0” as success.

In my experience, even when you re-compile the solution without changing anything at the code, your IIS will not restart.