There are basically two ways of working with Sitecore.
- Your solution, and code, is fully immersed in the Sitecore web site.
- Your solution, and code, is outside of Sitecore's web site and you use some post build process to deploy.
- The most important advantage is a clear understanding of the ownership of files in the solution. Everything checked into source control is explicitly owned by the solution being developed. All other files are owned by Sitecore or a third party package installed in Sitecore.
- I want to be able to distinguish my files from Sitecore's just by looking on the file system.
- If I need to ship the code to my client I simply want to zip up my 'workspace' and not have to wade through out-of-the box Sitecore files.
- I want my development environment to be as close as possible to a production environment. This means no .cs files in my web root
Here is the way I work and highly suggest you work as well.
- Use IIS and configure Sitecore somewhere other than C:\[Workspace]\[Client]\trunk\. For example, C:\Sitecore\[Client]\Website
- Create your Visual Studio solution (and projects) outside of the web root. i.e. C:\[Workspace]\[Client]\trunk\ClientWebsite.sln
- Add references to any Sitecore assemblies as needed. Make sure to set "Copy Local" to false as John West suggests.
- Use a post build step to copy the output of your compiled Web Application project to the location specified in step 1. Or, better yet, use Team Development for Sitecore to handle the deployment for you.
- To debug, you will need to make a change to the Web Application project. On the 'Web' tab of the properties for your Web Application project you should choose the "Use Custom Web Server" option and enter in your development Sitecore URL. Once this setting has been specified you can now press F5 to build your project and debug normally. This may require some IIS components to be enabled, depending on your system. This will also work for IIS running on a remote machine (and virtual machines) as long as remote debugging components are installed on the remote machine.
We, at Hedgehog Development, have done a good number of Sitecore sites this way and we do consider this a best practice. We are able to bring new developers onto a project in minutes and can roll out builds effortlessly.
I would love to get some feedback on this. Please let me know if you love working out of the web root as Sitecore suggests.
Author :- Sean Kearney