Avoiding IIS Restarts in a separated code environment, now with Sitecore Rocks

September 18, 2015 Rodrigo Peplau 0

This post is to bring some recent experiences from my last projects, as a continuation of my post “Avoiding IIS restarts with Robocopy in a Post Build event“.

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.

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.

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.

 

Categories: Architecture, Sitecore Rocks, Visual Studio