Master page with ASP.Net MVC Framework (CTP)

by Mike Linnen 30. December 2007 19:13

I have been playing with the new ASP.Net MVC Framework that is part of the ASP.NET 3.5 Extensions CTP release.  I really like how simplified the MVC Framework has made things.  One thing I wanted to try out is how would you leverage master pages for things that needed to be rendered on every page.  Something like a product category for an online store that only shows products that are in a given category when the user clicks on the desired category.  I wanted to be able to place this category list on the master page so it could be maintained in one place.  This blog post explains how I managed to accomplish this.

First make sure you download the ASP.NET 3.5 Extensions Preview and also the MVC Toolkit.  This example uses the Northwind database.  There are many other blog posts that explain how to create the MVC Solution so I will not go through those details here.  Basically I created an MVC Web Application and a separate Class library to hold the data model.  In the model I only added the following tables from the Northwind database: Categories, Orders, Order Details, Customers and Products.  I also made sure I had the MVCToolkit.dll referenced in my web project so I could use some of the advanced Html Helper classes.

In the web application project under the Models folder create a new class called DefaultDataView and add a property that can hold a list of Categories.  This class will be the default strongly typed data container that all other data containers will be derived from.


Create another data container class and call it ProductDataView in the Model folder of the web project.  This class will derive from the DefaultDataView.  Add a property to the class to hold a list of products.


Create a public partial NorthwindDataContext class in the model project and add a method to return the categories as a list.


Create a ProductController class to handle displaying the list of filtered products based on a passed in category id.  Notice how I am using the subclass ProductDataView to hold the list of categories as well as the filtered list of products.


Now lets get the master page to display a list of product categories.  Add a new div tag above the maincontent div tag in the Site.Master page. The logic just iterates over the list of categories emitting a link to the products list action.  Notice the use of the ActionLink method on the Html helper class.  Since the List Action on our Product Controller accepts a category Id as a parameter I can just append the category Id to the end of List and the parameter will be injected into the controller List method.


Create a view to display the list the products.


I also modified the Index and About methods on the HomeController to use the strongly typed data container and load the categories.  Since neither of these actions load any other view specific data I used the DefaultDataView as the object to transport data to the view for rendering.  


The end result when a user clicks on one of the categories is as follows.



As you can see it is very easy to split out common rendering logic into a master page even in the MVC Framework.  I used strongly typed data container objects as a way to send data to the view but I could have used the un-typed method just as easily.  I generally like to stay strongly typed as much as possible though.  I want compile time checks for heavy refactorying while developing in an agile environment.

Another interesting concept here was that I was able to stay away from using any code behind logic or server controls.  It is a big debate these days on if code behind should be used or not.  If you don't use code behind you will end up with some C# code mixed in with HTML which I am not convinced is good or bad.  In a lot of ways I think mixing HTML and C# makes the code hard to read.  I guess I have to try it for a while before I decide one way or the other.  The VS 2008 Intellisense support and the MVC Html helper class is what will make a mixed HTML and C# solution a success.

All in all I really like the MVC Framework and I think it will be a great tool for building complex and maintainable web applications.  I am certainly going to use this framework on future projects and I am looking forward to it's production release.

Here is the solution if you want to download it. (63.25 kb)

Code Coverage of web applications in .Net 2.0

by Mike Linnen 2. May 2006 22:36
Code Coverage of web applications in .Net 2.0

In my day job at JDA Software I have been looking at code coverage options for determining the effectiveness of our testing.  My team uses four types of tests to test the software we write.

  • Unit Tests - Tests focused on a single component of the application.  These tests are MSTests that exercise a specific software component and typically mock out any dependant components.
  • Integration Tests -  Tests focused on multiple components of the application.  These tests are MSTests that exercise a component and it's dependencies to ensure the components work together.
  • Manual Tests - Tests that are executed by are testers manually from a GUI interface. 
  • Automated functional test - Tests that are scripted in a fashion that can be repeated build after build to ensure the build is still functional.  Sometimes referred to regression testing.

The goal of implementing a code coverage process was to determine the effectiveness of the types of tests listed above.  Visual Studio 2005 Team Edition (for testers and developers) provides some nice code coverage features we wanted to tap into.  Code coverage of unit tests and some integration tests worked fine from the visual studio IDE.  But for the integration, manual and automation tests that used web services we began to run into problems.  The web services that where hosted under IIS where not getting covered.  After some research I determined that code coverage under ISS was not going to work.  So I started looking into alternatives.  One thing I noticed is that web service projects that where not hosted under IIS had no problem getting covered.  These types of projects used the development web server that comes with ASP.NET 2.0.   So I decided to look into using the same development web server in place of IIS for code coverage purposes.


The generic steps for establishing code coverage for web services is as follows:

  1. Turn on instrumentation for the binaries that you want to cover
  2. Start the coverage monitor
  3. Start the development web server for a specified unused port pointing to the folder that is supposed to represent the web service.
  4. Execute your tests
  5. Stop the development web server
  6. Stop the coverage monitor
  7. Review the results in Visual Studio 2005

For the following commands use the Visual Studio Command prompt.


Turning on instrumentation of assemblies from the command line is done by the following command:

vsinstr -coverage myassembly.dll


To start the coverage monitor you use the follwoing command:

start vsperfmon -coverage -output:mytestrun.coverage


To start the development web server use the following command:

start WebDev.WebServer /port:8080 /path:c:\mypath


To stop the development web server simply right click on the task bar icon for the web server and select stop


To shutdown the coverage monitor use the following command:

vsperfcmd -shutdown


We were now able to do code coverage of all types of tests that we planned on implementing.  Some of our test runs are going to executed by the build and some will be executed by the testers.  Since VS.Net 2005 supports the ability to merge code coverage results this should not be a problem to combine all runs into a single report that now shows how effective our tests really are.


Some references to articles that help me come to this conclusion:

Command Line code coverage:


Using WebDev.WebServer from the command line:,1895,1886246,00.asp

About the author

Mike Linnen

Software Engineer specializing in Microsoft Technologies

Month List