An approach to Sitecore Visual Studio Solution Structure

I am sure there have been dozens of similar posts over the years, but I thought I would run through my approach to structuring a visual solution to allow it to get along easier with Sitecore.

Firstly, I will come out and say the following: The Microsoft web publishing tools in visual studio are fine for small sites & solutions. Sitecore starts its life with > 8000 files out of the box. I personally don’t enjoy adding all of these files to a visual studio solution and don’t feel it is necessary or beneficial :D!!

Also – credit where its due, my idea’s have been inspired over the years by a mix of working with umbraco (and their best practice), a blog post from Mark Cassidy.

This process is a whole lot easier if the developers agree standards on their naming of their entries in their local hosts file. I generally recommend

MyCo.local

MyCo.database.local

Project Overview

So – with that in mind here we have an overview of the basic solution structure and what each project does.

MyCo.Platform

This project is simply a ‘placeholder’ project, its where the Sitecore web root will live, where IIS points to, where your site runs from. All it needs (and this is solely to allow debugging by pressing f5 – another bug bear of mine) is a (any) web.config included. It doesn’t matter at this stage what it has in it as I will explain later.

On disk (but not in the Visual Studio Solution) I will place a complete virgin copy of the version of Sitecore which I will be using.

Final point on the platform is to reference all of the Sitecore Binaries from its own bin folder (ensure you add these to your SCM of choice).

MyCo.Integration

Ok, so here we will keep any views / sublayouts / renderings / css / js / images / code / configuration that is related to the Sitecore installation as a whole. I generally like to keep things simple and mimic a folder structure similar to their final location within the final sitecore application. In here we also keep a full copy of the web.config & connectionstrings.config. Using the following simple .csproj modification, we can have these transform *ON BUILD* depending on the build configuration selected in visual studio. Within the default .csproj there will be an element as such , simply add the following

  <!-- this normally exists in every .csproj but is commented out-->
  <Target Name="AfterBuild">
    <!-- Add this yourself -->
    <TransformXml Source=".\Web.config" Transform=".\Web.$(Configuration).config" Destination="..\..\(path to platform)\Web.config" />
  </Target>

With most solutions I have worked with (especially if Team Development For Sitecore is in use), we as developers have access to usually our local machine development copy of sitecore and a shared development (and potentially) QA instance, by using build config transformations, it allows us to test the configs as will run in different environments and also gives a helping hand when it comes to looking at CI / CD services.

In general, I build config transform web.config, connectionstrings.config and usually 1 file in the integration/App_Config/include folder to allow environment specific sitecore config.

MyCo.SiteX

This project will contain views / sublayouts / renderings / css / js / images / code / configuration that is relevant to the individual site. Remember that Sitecore is a multi platform, multi lingual solution and that at some point, your client (even if they don’t forsee it now) may want to add additional sites / microsites / member sites whatever into their fantastic Sitecore implementation.

Other class libraries

There will no doubt be other projects that are to be included, these I will leave to the discretion of the developers, but in general, I tend to try and keep concerns grouped within discrete class libraries and as best as possible, attempt to keep a clear understanding within the team of what these responsibilities are.

Post Build Scripts

Again, on this point – I choose robocopy and batch files cause they are simple, others may opt for powershell. Otherwise the process is simple – create post build events that copy your code from the MyCo.Integration and MyCo.SiteX projects into the location where the platform resides.

Gotcha!! – make sure if you are using build configuration transformations not to copy the ..config files – ESPECIALLY if its in the app_config/include folder.

Supporting software

In general, the structure I have described works great for developers, however it comes with the drawback that every time to make quick changes to css / js / assets / .cshtml / .ascx files, the solution needs to be built. This can be easily alleviated by using a tool such as SecondCopy by Centered Systems to monitor the various folders for files that change and perform the copy immediately. In my experience, this happens faster than you can change between Visual Studio and the web browser.

The result

Assuming all has gone well, you should end up with a copy of Sitecore in your platform folder that is DEPLOYABLE IMMEDIATELY (if you don’t copy the .csproj). If you build in a set up configuration for ‘UAT’ it will already have the appropriate configuration, it will only have compiled binaries

Advertisements

One thought on “An approach to Sitecore Visual Studio Solution Structure

  1. Pingback: Don’t fight the framework Pt I (Sitecore) | cardinalcore

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s