How To Architect Your Sitecore Website With MVC

There are many ways to set-up your Sitecore website.  My personal preference is to use TDS and Glassmapper, however, on some projects the budget might not quite fit.  In today’s tutorial, I’m going to cover one solution for setting up your Visual Studio solution, how to write your code and how to debug it.

Installing Sitecore

In order to start building MVC websites using Sitecore, the first step is to install Sitecore.  If you are completely new, then I recommend reading this,  How To Install a Sitecore Instance Using the Sitecore Instance Manager.

In this scenario, we’re not going to build anything inside the Sitecore Website folder.  All the code, CSS, HTML will be written in a separate folder and effectively copied in, using the visual studio publish method.  Using this method means we upgrade Sitecore easily, delete the website to rebuild it easily, and make our source control repo a little easier to manage.

Now, this approach does have some downfalls.  Reading this, you might be wondering why this adds a bit more complexity to the solution. When you start writing code you need to do a publish each time.  Also, you might be wondering how do you debug?  It’s pretty simple… attach the debugger to IIS and your breakpoints will fire (more on this later).

Creating Your MVC Solution

As we are not building inside the Sitecore folder, we need to create a project that contains a ‘Controller’, ‘Models’ and ‘Views’ folder.  To do this we simply create an empty MVC project and then delete the bits we don’t need.  So, in Visual Studio create a new ASP.NET Web Application project.


Select an MVC project, you don’t want to include anything else.  You also want to create the site without all the OWIN crap, so don’t forget to click ‘Change Authentication’



Now we have a solution, we want to delete all the things that we don’t want to publish into the ‘Website’ folder that contains our Sitecore instance.  In this example, I’m removing everything except the packages.config, Controllers, Views and Models.


In your scenario, you might want to keep the web.config and global.ascx files to write custom logic in.  To keep this tutorial simple, I’m removing them… but it’s up to you.

Now we have the skeleton outline for our project, we still have a few tweaks to do.  In your ‘Views’ folder, you should have a web.config. In here you need to make sure you have the Sitecore MVC namespace added.

<add namespace="System.Web.Mvc" />
<add namespace="System.Web.Mvc.Ajax" />
<add namespace="System.Web.Mvc.Html" />
<add namespace="System.Web.Optimization"/>
<add namespace="System.Web.Routing" />
<add namespace="Sitecore.Mvc" />
<add namespace="JonDJones.SiteCore.Mvc" />

I usually add my web projects default namespace as well.

Next thing is to add references to the Sitecore assemblies.  In your Sitecore instances bin folder, copy the Sitecore.MVC and Sitecore.Kernel assemblies.  Create a new folder called ‘Lib’ in the same directory as your Sitecore instances websites and data folder (this is probably the same level you want to have your MVC project as well).


Copy the Sitecore assemblies into the ‘Lib’ folder and then reference them in your web project through Visual Studio -> Add References.

At this point, I would recommend checking your code into your source control repo, or at a minimum creating a file copy of the whole folder.

Publishing Your Code Into The Sitecore Instance

The next step in the process is now publishing the code into the Sitecore folder.  In Visual Studio, right click on the MVC project and select ‘Publish’.  From here you’ll see the Visual Studio Publish Wizard.


Hit custom and add any name you want, I’m calling my publish Debug, but you can call it dev etc..


Set your publish method to File System and point the directory to your Sitecore Instances websites folder.


Set your configuration to ‘Debug’ mode and you are all set.  Do a publish and now all your views and code should be copied into your Sitecore instances website.


At this point, we now have one project that will contain all of our custom code, we have a default Sitecore instance that we use a Visual Studio publish to copy our code into.  The next important thing you need to know is how to debug it.  As we set-up the publish in debug mode, when our assemblies deploy we can deploy our Sitecore website from our solution without having to worry about the website at all.

In order to do this, all you need to do is Attach Your Debugger to the IIS worker process for the Sitecore website. When you run your code the debugger will still hit. In Visual Studio, click Debug from the top menu and select ‘Attach To Process’.


By default the IIS process won’t appear in the debug list, so you will need to select ‘Show Processes From All Users’ and then find the ‘w3wp.exe’ process. I personally recommend installing ReAttach to make your life a lot easier when attaching.  Now, when you set your Sitecore website up to use a rendering that has a controller, you can debug your work 🙂

This guide doesn’t cover how to write your code and configures Sitecore directly to get your code working in Sitecore.  If you want to learn how to do that, I would recommend reading ‘How To Make Sitecore Use a MVC Controller, Controller Renderings Explained’.


In today’s guide, we’ve covered quite a lot.  I’ve covered probably the most common way most companies set-up their web projects with Sitecore when not working with TDS.  There are other alternatives that I will cover at a later date.  We created a basic empty MVC project to add our custom code in that is completely seperate from your Sitecore website.  This separation makes life a lot easier when you want to upgrade.  To get the code into the Sitecore website we use a visual studio publish.  In this seperate project we can still debug our code even though we are not directly working in the website folder by attaching the visual studio debugger to the IIS process

Jon D Jones

Software Architect, Programmer and Technologist Jon Jones is founder and CEO of London-based tech firm Digital Prompt. He has been working in the field for nearly a decade, specializing in new technologies and technical solution research in the web business. A passionate blogger by heart , speaker & consultant from England.. always on the hunt for the next challenge

More Posts

4 replies

Trackbacks & Pingbacks

  1. […] re-build your Sitecore solution. If you would like to read more about this approach you can read, How To Architect Your Sitecore Website With MVC. The point of the design is that you can delete your web root entirely, re-publish and be up and […]

  2. […] When I did the upgrade I ran into a lot of issues, this generally meant that I needed to revert what I did and start from scratch several times. The recommend approach by many to architect a Sitecore solution is to use the clean Sitecore instance approach and publish all your changes into it, as discussed here: How To Architect Your Sitecore Website With MVC. […]

  3. […] In a lot of Sitecore installs, teams have decided to stop working within the webroot. If you are new to this concept then I suggest you read ‘How To Architect Your Sitecore Website With MVC‘. […]

  4. […] Sitecore renderings are the way developers can render a page or a part of a page in Sitecore. Sitecore has many different types of renderings bu when we work with MVC the two main renderings you will be working with are view renderings and controller renderings. A view rendering can be used for components that have no or very close to no logic in it. Simply a view rendering is like calling a partial view in vanilla MVC… basically it doesn’t have a controller! View rendering work by defining a .cshtml view file and registering it with Sitecore. A controller rendering on the other hand does have a controller and sub-sequently needs a little bit more configuration and code. In today’s guide I’m going to create a controller rendering to display some text on a page using MVC. The solution in this example is built upon How To Architect Your Sitecore Website With MVC. […]

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

Your email address will not be published. Required fields are marked *