This is the first post in a series where I show you step-by-step how to get your first ASP.NET MVC website up off the ground. By the end of this series, we’ll have a working web application for registering community college students. More importantly, you’ll have a template you can easily follow for your own projects.
In this first post, I’ll show you how to set up your visual studio solution.
In this series, we’ll use these tools:
- ASP.NET MVC is a free, fully Microsoft-supported product that, unlike ASP.NET WebForms, gives you complete control over your application. You can use the Web Platform Installer or download the MSI installer package directly.
- MVCContrib – This is the contrib project for ASP.NET MVC. It adds additional functionality to and makes ASP.NET MVC easier to use.
- jQuery – This is an open-source javascript library that does just about everything, and supports every major modern browser out there. Yes, you hate javascript. You’re going to love jQuery. I promise. This is included in the ASP.NET MVC download.
- NHibernate 2,1 is a well-known, mature, open source object relational mapper (ORM). It helps you get on with writing you application, instead of spending days, weeks, or even months writing a data access layer.
- Fluent NHibernate – This is a library for configuring NHibernate using an english-like syntax. It saves you from hacking through dozens of XML configuration files. Scroll to the bottom of the downloads page and get the latest compiled binaries.
- Ninject is my personal favorite dependency injection (DI) / inversion of control (IoC) framework. It allows you to automatically wire up services to your objects. If you’ve never done DI or IoC before, you’re going to have a great “ah-ha!” moment. We’ll be using version 1.
You will also need:
- .NET Framework 3.5 SP1
- Visual Studio 2008 SP1. The Web Dev Express version may also work. I haven’t tried it.
- The latest version of NUnit
- Any major database supported by NHibenate. This can range from Oracle to SQL Server to MySQL to SQLite. I’ll be using SQL server in my examples, but if you have a favorite, you can easily use that instead.
I also suggest you get some kind of source control. You’ll want to play around and experiment as we go along.
OK. You’ve downloaded all of that? Good. Let’s talk terminology for a minute.
- MVC stands for Model-View-Controller. This separation of responsibilities allows you greater flexibility to adapt and change your application.
- Model – This term refers to all of your entities – your business objects. In terms of a billing application, this would be your invoices, invoice items, customers, products, etc. – all of the “real-world things” your application represents.
- View – Each view presents a specific business object in a specific way. For example, you may have a view for editing customer data and another for displaying an invoice. You can also think of views as the pages that make up your application.
- Controller – Controllers are the glue that bind a view to a specific entity in your model. They are also responsible for all of the flow of your application from page to page.
- Inversion of Control (IoC) is the concept that your objects do not explicitly create the services that they need. Instead, they get them from some container of services. Hence, the inversion. Your classes don’t specify a specific implementation of the service, only the type of service they need – an interface. This loose coupling allows you to easily swap out implementations of those services without having to touch every class that uses them. I’ve seen two major flavors of IoC: Service Locator and Dependency Injection.
- A Service Locator is a central container where you specify which implementations of each service your application will use. Your objects request service implementations from the service locator. A service locator is typically a singleton, which is why I don’t like it.
- Dependency Injection (DI) is a method of wiring your objects to the services they depend on as the object is built. These services are typically passed in as parameters on the object’s constructor. The object itself is built by the DI framework, in this case, Ninject. The process of building dependencies can be many layers deep. The Ninject Dojo has a great tutorial on dependency injection. If you’re new to IoC, it’s a great place to start learning. Once you have the “ah ha!” moment, the migraine will stop and you’ll never look at code the same again. I promise.
Setting up the solution
Disclaimer: This is how I have learned to set up my projects. I’m sure others have differing opinions. I’d love to hear them. I don’t claim to be an expert, just a curious professional looking to improve.
Setting up the project is fairly straight-forward. We’ll do almost everything through Visual Studio. Just follow these steps.
-
Create the solution and web project
In Visual Studio, start a new ASP.NET MVC Web Application. This template is added to Visual Studio when you install ASP.NET MVC. I’ll be calling my solution NStackExample.

There’s a few things to note here. First, we’re creating a solution directory. Second, notice how we’ve appended .Web to the name of our web project, but not the solution.
This web project will contain all of the views. Despite the implied direction from Microsoft through the ASP.NET MVC template, it won’t contain the model or the controllers.
-
Create a library directory
Inside your solution directory, create a directory for all 3rd party libraries used in your project. I call mine Solution Items. The name you give it isn’t as important as the fact that you have one. So, in the example shown above, I would create the directory C:\Users\Jason\Documents\Visual Studio 2008\Projects\NStackExample\Solution items. Copy these 15 assemblies to the library directory:
- From MVCContrib:
- MVCContrib.dll
- Microsoft.Web.Mvc.dll
- System.Web.Abstractions.dll
- System.Web.Mvc.dll
- System.Web.Routing.dll
- From NHibernate:
- Antlr3.Runtime.dll
- Iesi.Collections.dll
- log4net.dll
- NHibernate.dll
- Castle.Core.dll
- Castle.DynamicProxy2.dll
- NHibernate.Bytecode.Castle.dll
- FluentNHibernate.dll from Fluent NHibernate
- From Ninject:
- Ninject.Core.Dll
- Ninject.Framework.Mvc.Dll
- From MVCContrib:
-
Create the core project
This is your main project. It will contain your model, as well as interfaces for any services and strategies your application will use. It will not contain the implementation of any of those services. Those go in separate, easily replaceable assemblies.
Add a new “Class Library” project to your solution. We’ll call this project NStackExample.Core.
Now, right click on the project and select properties, then click on the Application tab on the side. In the root namespace field, remove .Core.

We’re doing this so our entities will be named NStackExample.Entity1, NStackExample.Entity2, etc. but the assembly will be NStackExample.Core.dll, which better describes it’s purpose. -
Create the controller project
Next, create another project specifically for the controllers of your MVC project. We’re going to call it NStackExample.Controllers. Yes, the Microsoft ASP.NET MVC project template already has a folder for them. We’re not going to use that folder because I think they should be better separated from the content of your website.
-
Clean up your projects
Delete all of these:
- The Class.vb or Class.cs files in the Core and Controllers projects.
- In the NStackExample.Web project, delete:
- The Controllers folder and all of it’s contents.
- The Models folder
- The Microsoft AJAX script libraries in the Scripts folder
- The Home and Account folders inside the Views folder
- The LogOnUserControl in the Views folder
-
Set up your references
This is pretty straight forward.
- First, in your web project, remove the references to System.Web.Abstractions, System.Web.Mvc, and System.Web.Routing.
- Next, in your web project, from the library directory we created in step 2, add references to these 10 assemblies:
- log4net.dll
- Microsoft.Web.Mvc.dll
- MvcContrib.dll
- NHibernat.Bytecode.Castle.dll
- NHibernate.dll
- Ninject.Core.dll
- Ninject.Framework.Mvc.dll
- System.Web.Abstractions.dll
- System.Web.Mvc.dll
- System.Web.Routing.dll
- In the web project, add references to the controllers project and the core project.
- In the controllers project, add references to these 3 assemblies:
- log4net.dll
- MvcContrib.dll
- System.Web.Mvc.dll
- In the controllers project, add a reference to the core project.
Did you notice how we didn’t add any references in our core project? That’s intentional. When a project needs to reference your model or service interfaces, you don’t want to have required dependencies on other libraries and frameworks.
That’s it. Your solution is set up and you’re ready to start coding. In the next post, we’ll start building the model, configure NHibernate, and set up the database.
Jason
- Blogged-out for the night




Trackback: progg.ru
#1 by ANaimi on August 8th, 2009
Hello Jason. Looking forward for the rest of the series. Thanks!
#2 by Buzzy on August 9th, 2009
Hi there Jason. Looking forward for the rest of the series. You could have skipped this part:p :=)
#3 by Jason on August 9th, 2009
@Buzzy – In most cases, you’re probably right, but those monolithic single-project solutions come from somewhere – mostly my early 20s.
#4 by Tim on August 9th, 2009
Thanks for doing this! – subscribed
#5 by yassir on August 9th, 2009
Looking forward to the next article , Too bad you won’t be using C#
#6 by Jason on August 9th, 2009
I’ll use both, because I know not everyone thinks in VB…
Pingback: How-To: Using the N* stack, part 1 « BASICly everything | OddStall.Com
#7 by Mike C. on August 9th, 2009
Is it just me or Ninject.Framework.Mvc.Dll is not in the latest of Ninject release?
#8 by fgmmgf on August 9th, 2009
I have the same problem, it’s not there..
#9 by Jason on August 9th, 2009
@Mike C, @fgmmgf: Sorry. Ninject.Framework.Mvc is part of Ninject 1.5, meaning you’d have to download it with SVN, update the references, and build it yourself. It’s a process you should probably get familiar with, but when I post the source code, it’ll be included. You can grab it from there.
#10 by franklingm on August 9th, 2009
Thank god you’ll be using C# too
#11 by NoelR on August 9th, 2009
Looking foward to your next release
#12 by Zohaib Uddin Khan on August 10th, 2009
Could you please tell me, why in Step # 6, point # 3, you are references the core project in the web project? Since, Web project only need to be depend upon Controller.
#13 by Jason on August 10th, 2009
The core project contains our model – the entities. The web project contains our views. Our views will be projecting (displaying) data from the model, so the views must know about the model. In fact, in most cases, our view pages will actually be strongly-typed: System.Web.Mvc.ViewPage(Of SomeEntityType)
Pingback: How-To: Using the N* Stack, part 2 « BASICly everything
Pingback: How-To: Using the N* Stack, part 2 - NHibernate blog - NHibernate Forge
Pingback: NHibernate Talk 8/11/09 - Travis.Net.Blog
Pingback: NHibernate Talk 8/11/09 | I love .NET!
Pingback: Reflective Perspective - Chris Alcock » The Morning Brew #410
Pingback: NHibernate Talk 8/11/09 | rapid-DEV.net
Trackback: DotNetShoutout
Pingback: How-To: Using the N* Stack, part 3 « BASICly everything
Pingback: How-To: Using the N* Stack, part 3 - NHibernate blog - NHibernate Forge
Pingback: How-To: Using the N* Stack, part 4 « BASICly everything
#14 by kurt schroeder on August 21st, 2009
Jason, I’m enjoying this series. Thanks. A quick note on fluent NHibernate: there have been some changes as i’m sure you know and this is just a reminder to all to download or branch the source as often as possible. WithLengthOf is now Length and there are other language changes. The changes are self explanatory meaning its a minor issue to adjust your tutorial.
Thanks Again
KES
Pingback: Part 5: Fixing the Broken Stuff « BASICly everything
Pingback: Part 5: Fixing the Broken Stuff - NHibernate blog - NHibernate Forge
Pingback: Part 6: Ninject and MVC or How to be a Web Ninja « BASICly everything
Pingback: Part 6: Ninject and MVC or How to be a Web Ninja - NHibernate blog - NHibernate Forge
#15 by Dave Hanna on September 1st, 2009
Jason,
I know I’m getting ahead of you here, but when you create the Controllers as a separate project, rather than leaving them in the Controllers folder underneath the .Web project, what’s the magic incantation to get the MVC framework to look for your controllers in the Controllers project space? I’m sure there is one, because the MVC documentation says it looks for them in the Controllers folder BY DEFAULT, but I can’t find anywhere that it says how to change the defaults (plus I know you wouldn’t have put them in a separate project if there WASN’T a way to reach them!)
#16 by Dave Hanna on September 1st, 2009
Jason,
Disregard the above question. Stupid mistake – I hadn’t included the Controllers project in the References for the Web project. When you do that, it happens automatically.
#17 by Jason on September 2nd, 2009
@Dave – In part 6, we use Ninject’s AutoControllerModule to register all of our controllers with the Ninject Kernel. You specify the assembly in the constructor.
Then, to get ASP.NET MVC to ask Ninject for the controllers, you have two options. First, you can use ControllerBuilder.Current.SetControllerFactory to point it at a Ninject controller factory. The second option, which I prefer, is to change your app (in Global.asax) to inherit from Ninject.Framework.Mvc.NinjectHttpApplication instead System.Web.HttpApplication.