At my new project I am responsible for configuration management. We are using Visual Studio 2010 Premium and Team Foundation Server 2010 (TFS). The app we are going to build is an ASP.NET MVC Web application as the presentation layer that communicates to the data store via a services layer . The data store will be a SQL Server database. For now the service layer is not implemented, because the build is the first thing I do.

Continuous Integration
Because the app is going to be a product that is very important for the organization (core business), I am going to use Continuous Integration (CI), every check-in will result in building of the product and running all our unit-tests. CI is very easy to achieve with TFS.

Nightly Build
In addition to the unit-testing and building of the product, I want a nightly build where the build also deploys the application to a test web server, deploys the database to a separate test SQL Server and when all these tasks have succeeded run automated web tests on the web application, so the state of the application is always known and the testers will have a report with the test results first thing in the morning. I am aware of Lab Management, which makes these configuration’s easier to manage, but as I mentioned we are using VS Premium for now, so I can not leverage Lab Management at this moment in time.

To deploy a web application using Team Build I want to leverage MSDeploy. I had to install MSDeploy on the test webserver, the application will be deployed on. The installation and configuration of MSDeploy was not straightforward to say the least.

Here are some links to help with that:

Auto deploy Web application using Team Build
After MSDeploy is working on the webserver, the deployment of web applications using Team Build 2010 is a question of setting the right MSBuild arguments in the new Build settings window of the Build definition feature.

Process tab build settings build definition Team Build 2010
Process tab build settings build definition Team Build 2010

The following arguments where needed to make my configuration work, deploying via MSDeploy to another machine running IIS:


/p:DeployOnBuild=True /p:DeployTarget=MSDeployPublish /p:MSDeployPublishMethod=RemoteAgent /p:MsDeployServiceUrl="machinename webserver/msdeployagentservice" /p:DeployIisAppPath="BuildTest" /p:username="domain\Username" /p:password=P@ssword

Listing 1: MSBuild arguments

The most interesting arguments are:
MSDeployPublishMethod: InProc or RemoteAgent
MSDeployServiceUrl, because I use RemoteAgent, I could not use https://machinename:8172/msdeploy.axd (msbuild puts http before the url…), I took some time to figure out that the service listens to http://machinename/MSDEPLOYAGENTSERVICE also.

Web.config transformation
.NET Framework 4.0 comes with the web.config transformation feature, a web.config has a shadow file per build type, so a web.debug.config and a web.release.config.

<connectionstrings><add name="BuildtestConnectionString" connectionstring="Data Source=SQLMACHINE;Initial Catalog=DATABBASENAME;Integrated Security=false;uid=user;password=P@ssw0rd" providername="System.Data.SqlClient" xdt:transform="SetAttributes" xdt:locator="Match(name)" /></connectionstrings> 

Listing 2: web.config transform web.release.config

When the project is build as a release build, the values of the attributes in the connectionstring are changed to reflect the values in the connectionstring in listing 2.

This was all I needed to do to make Team Build deploy my web app to another server, I will report on how I configured Team Build to deploy the database (an vsts database project) in a follow up post.

Henry Cordes
My thoughts exactly…

Ever since ASP.NET MVC Framework 2.0 has released I did not have a change to work with the new validation logic.
The DataAnnotations that are the only place where you have to keep logic related to validation, no more having to write the same logic in several places.

Today I wanted to give it a try, since I can delete lots of code from my views, if it works as promised.
I want to use jquery.validate.js (ships out of the box with Visual Studio 2010 and ASP.NET MVC Framework 2.0. But to my surprise only files that support the MicrosoftMvcValidation.js are available with the project template for a ASP.NET MVC 2 Web Application.

With the ASP.NET MVC 2 RTM release a file named MicrosoftMvcJQueryValidation.js was shipped. I downloaded the RTM once again and got the MicrosoftMvcJQueryValidation.js file.

In my view I now add the following script tags:

Listing 1: Script tags

Enable validation on a view clientside
Than below script tags, I put the following call to enable validation on the client.

<% Html.EnableClientValidation(); %>

Listing 2: Html.EnableClientValidation

This call (listing 2) bubbles up the validation rules as Json data, the MicrosoftMvcJQueryValidation.js leverages jQuery to do the client side validation.

I added the code from listing 1 and 2 onto the  logon.aspx from a vanilla ‘file > new project > ASP.NET MVC 2 Web Application’ and it worked as I expected.

Contents MicrosoftMvcJQueryValidation.js
Because it took me some effort to get the MicrosoftMvcJQueryValidation.js I will put the code here:


// register custom jQuery methods

jQuery.validator.addMethod("regex", function(value, element, params) {
    if (this.optional(element)) {
        return true;

    var match = new RegExp(params).exec(value);
    return (match && (match.index == 0) && (match[0].length == value.length));

// glue

function __MVC_ApplyValidator_Range(object, min, max) {
    object["range"] = [min, max];

function __MVC_ApplyValidator_RegularExpression(object, pattern) {
    object["regex"] = pattern;

function __MVC_ApplyValidator_Required(object) {
    object["required"] = true;

function __MVC_ApplyValidator_StringLength(object, maxLength) {
    object["maxlength"] = maxLength;

function __MVC_ApplyValidator_Unknown(object, validationType, validationParameters) {
    object[validationType] = validationParameters;

function __MVC_CreateFieldToValidationMessageMapping(validationFields) {
    var mapping = {};

    for (var i = 0; i < validationFields.length; i++) {
        var thisField = validationFields[i];
        mapping[thisField.FieldName] = "#" + thisField.ValidationMessageId;

    return mapping;

function __MVC_CreateErrorMessagesObject(validationFields) {
    var messagesObj = {};

    for (var i = 0; i < validationFields.length; i++) {
        var thisField = validationFields[i];
        var thisFieldMessages = {};
        messagesObj[thisField.FieldName] = thisFieldMessages;
        var validationRules = thisField.ValidationRules;

        for (var j = 0; j < validationRules.length; j++) {
            var thisRule = validationRules[j];
            if (thisRule.ErrorMessage) {
                var jQueryValidationType = thisRule.ValidationType;
                switch (thisRule.ValidationType) {
                    case "regularExpression":
                        jQueryValidationType = "regex";

                    case "stringLength":
                        jQueryValidationType = "maxlength";

                thisFieldMessages[jQueryValidationType] = thisRule.ErrorMessage;

    return messagesObj;

function __MVC_CreateRulesForField(validationField) {
    var validationRules = validationField.ValidationRules;

    // hook each rule into jquery
    var rulesObj = {};
    for (var i = 0; i < validationRules.length; i++) {
        var thisRule = validationRules[i];
        switch (thisRule.ValidationType) {
            case "range":
                    thisRule.ValidationParameters["minimum"], thisRule.ValidationParameters["maximum"]);

            case "regularExpression":

            case "required":

            case "stringLength":

                    thisRule.ValidationType, thisRule.ValidationParameters);

    return rulesObj;

function __MVC_CreateValidationOptions(validationFields) {
    var rulesObj = {};
    for (var i = 0; i < validationFields.length; i++) {
        var validationField = validationFields[i];
        var fieldName = validationField.FieldName;
        rulesObj[fieldName] = __MVC_CreateRulesForField(validationField);

    return rulesObj;

function __MVC_EnableClientValidation(validationContext) {
    // this represents the form containing elements to be validated
    var theForm = $("#" + validationContext.FormId);

    var fields = validationContext.Fields;
    var rulesObj = __MVC_CreateValidationOptions(fields);
    var fieldToMessageMappings = __MVC_CreateFieldToValidationMessageMapping(fields);
    var errorMessagesObj = __MVC_CreateErrorMessagesObject(fields);

    var options = {
        errorClass: "input-validation-error",
        errorElement: "span",
        errorPlacement: function(error, element) {
            var messageSpan = fieldToMessageMappings[element.attr("name")];
            error.attr("_for_validation_message", messageSpan);
        messages: errorMessagesObj,
        rules: rulesObj,
        success: function(label) {
            var messageSpan = $(label.attr("_for_validation_message"));

    // register callbacks with our AJAX system
    var formElement = document.getElementById(validationContext.FormId);
    var registeredValidatorCallbacks = formElement.validationCallbacks;
    if (!registeredValidatorCallbacks) {
        registeredValidatorCallbacks = [];
        formElement.validationCallbacks = registeredValidatorCallbacks;
    registeredValidatorCallbacks.push(function() {
        return theForm.valid();


// need to wait for the document to signal that it is ready
$(document).ready(function() {
    var allFormOptions = window.mvcClientValidationMetadata;
    if (allFormOptions) {
        while (allFormOptions.length > 0) {
            var thisFormOptions = allFormOptions.pop();

Listing 3: Contents MicrosoftMvcJQueryValidation.js

Henry Cordes
My thoughts exactly…

I downloaded the Hanselminutes podcast nr 202, and only by reading in the title the word “WebformsMVC”, my interest was drawn.
I googled for it and found A framework for using the MVP pattern in Webforms. I see the  positive side, familiarity if you know webforms, using your control-libraries, but still get the benefits of testability and the benefits you get with a decoupled architecture.

Also want to know more? Take a look at the featureset here.

My thoughts exactly…
Henry Cordes

In a recent post, I talked about a project where the requirement is to create modules that can be used in an ASP.NET webapplication and in Sharepoint 2007, where I wanted to have separations of concerns. The way I solved this is: creating ASP.NET UserControl libraries (inside their own ASP.NET Webapplication project) that we package inside Sharepoint webparts. During development we test and debug the modules in a separate ASP.NET webapplication. We use pre-build events to copy the ascx files from the UserControl libraries to this webapplication and because we set a reference to the  webapplications, the dll’s are available already. Scott Guthrie has a tutorial on his website that explains how we do this. 

In the post I said I wanted to leverage Unity as our Inversion of Control Container and I was thinking about using the WCSF, because I wanted to use the MVP design pattern.
After some prototyping, I came to the conclusion using WCSF was not practical for our purpose.  Still I wanted to use the MVP pattern, because of unit-testing and loose coupling needs. I could not use MVC, because of the Sharepoint requirements.

The Model-View-Presenter pattern is different from MVC or Model-View-Controller in the sense that with MVC the Controller is where the request comes in and the Controller is where you control (what’s in a name…) your View and what you get from the Model.
With MVP the request comes in at the View, the View than delegates it to the Presenter that will get data from the Model and returns it back to the View.

Model View Presenter pattern Pic 1.: Model View Presenter pattern

The solution I finally found to be working really good is using the MVP design pattern and Unity in the following manner.

Model View Presenter UserControl diagramPic 2.:Model View Presenter Class Diagram 

As you can see in picture 2 the Model, View and Presenter all are implementing an interface. Practicing Interface based programming sets the door wide open for leveraging an Inversion of Control container, or IoC container. In my case I am using Unity, because I am doing this project for a client who is heavily into using Microsoft tools. All Presenters are derived from the abstract class Presenter<TView>.

Pic 3.: Interfaces used in MVP diagram

Why the interfaces?
Using Interfaces for all these parts of our component makes it easy to use an IoC container. Our objects are loosely coupled and we can switch out the concrete implementations easily, because we program against the interfaces. Say we want to test the Presenter and to avoid having a dependency on a data store or some service we want to switch the Model out for an implementation that returns the same hard coded objects each time. all we have to do is create this ‘mock’ Model that implements the IZaakModel interface (on Picture 3) and we are good to go.
To make this even more appealing: if we use an IoC container we only have to change the configuration in the container to start to use this other Model…

Here a listing of the Presenter of picture 2.

   1:  using System;
   2:  using Microsoft.Practices.Unity;
   3:  using HC.Interfaces.Zaak;
   4:  using HC.Mvp;
   5:  using HC.Domain;
   7:  namespace HC.Presenters.Zaak
   8:  {
   9:      public class ZaakDetailPresenter: Presenter<IZaakDetailsView>, IZaakDetailsPresenter
  10:      {
  11:          private Zaak CurrentZaak{ get; set;}
  13:          [Dependency]
  14:          public IZaakService Service { get; set;}
  16:          private IZaakModel _model;
  17:          public ZaakDetailPresenter([Dependency] IZaakModel model)
  18:          {
  19:              _model = model;
  20:              _model.CurrentZaakChanged += new EventHandler<DataEventArgs<Zaak>>(_model_CurrentZaakChanged);
  21:          }
  23:          void _model_CurrentZaakChanged(object sender, DataEventArgs<Zaak> e)
  24:          {
  25:              CurrentZaak = e.Data;
  26:              View.ShowCurrentZaakOnView(CurrentZaak);
  27:          }
  29:          public override void OnViewInitialized()
  30:          {
  31:              base.OnViewInitialized();
  32:          }
  34:          public override void OnViewLoaded()
  35:          {
  36:              View.ShowCurrentZaakOnView(CurrentZaak);
  37:          }
  39:      }
  40:  }

Listing 1: Presenter


Because the Presenter (in listing 1) is derived from the Presenter<TView> abstract class, it is necessary to tell the Presenter of what type its View will be. Because we  use the Interface again, all we have to do is let Unity (our IoC container) do the work to supply the concrete implementation for this Interface. On line 13 of listing 1 we see the Dependency attribute, in this case the attribute will be used by Unity to resolve the concrete implementation of the IZaakService interface for the property (Service) on which the attribute is decorated that is configured.

The Model
The Model from picture 1 implements the Interface IZaakModel, and is responsible for getting the data if the Presenter asks for it and for letting the Presenter know that it has got this data and handing it over to the Presenter.

   1:  using System;
   2:  using Microsoft.Practices.Unity;
   3:  using HC.Domain;
   4:  using HC.Mvp;
   5:  using HC.Interfaces.Zaak;
   7:  namespace HC.Models
   8:  {
   9:      public class ZaakModel : IZaakModel
  10:      {
  11:          public event EventHandler<DataEventArgs<Zaak>> CurrentZaakChanged;
  13:          private IZaakService _datasource;
  14:          private Zaak _CurrentZaak;
  16:          public ZaakModel([Dependency] IZaakService datasource)
  17:          {
  18:              _datasource = datasource;
  19:          }
  21:          #region IZaakModel Members
  22:          public void LoadCurrentZaakById(int zaakId)
  23:          {
  24:              CurrentZaak = _datasource.GetZaakById(zaakId);
  25:          }
  27:          public Zaak CurrentZaak
  28:          {
  29:              get { return _CurrentZaak; }
  30:              set
  31:              {
  32:                  _CurrentZaak = value;
  33:                  OnCurrentZaakChanged(new DataEventArgs<Zaak>(_CurrentZaak));
  34:              }
  35:          }
  37:          public virtual void OnCurrentZaakChanged(DataEventArgs<ZaakExtended> e)
  38:          {
  39:              if (CurrentZaakChanged != null)
  40:                  CurrentZaakChanged(this, e);
  41:          }
  42:          #endregion
  43:      }   
  44:  }

Listing 2.: The Model

In listing 2 the Model is listed, is also depending on Unity for the resolving of the concrete implementations for interfaces. It implements IZaakModel  and thus implements the LoadCurrentZaakById method and the CurrentZaak property. When the  LoadCurrentZaakById (line 22, listing 2) is called it fills the CurrentZaak property calling a method on an object that implements the IZaakService interface (the private _datasource variable that is set by the ZaakModel constructor using Unity).

When the CurrentZaak property is filled the setter (line 30, listing 2) is used and in the setter the CurrentZaakChanged event is raised. Every object that subscribes to this event will recieve the change.

In listing 1 we can see on line 20 the Presenter has attached the event and will recieve this change. On line 26 of listing 1 the ShowCurrentZaakOnView method of the View is called.

The View
In ASP.NET a request will load an aspx page, the view is where the request starts, the view than delegates responsibility to the Presenter.

   1:  using System;
   2:  using Microsoft.Practices.Unity;
   3:  using HC.Interfaces.Zaak;
   4:  using HC.Mvp;
   5:  using HC.Domain;
   7:  namespace HC.ZaakModule
   8:  {
   9:      public partial class ZaakDetails : System.Web.UI.UserControl,IZaakDetailsView
  10:      {
  11:          IZaakDetailsPresenter _presenter;
  12:          public event EventHandler UserControlLoaded;
  13:          [Dependency]
  14:          public IZaakDetailsPresenter Presenter
  15:          {
  16:              get
  17:              {
  18:                  return _presenter;
  19:              }
  20:              set
  21:              {
  22:                  if (value == null)
  23:                      throw new ArgumentNullException("value is null");
  25:                  _presenter = value;
  26:                  _presenter.View = this;
  27:              }
  28:          }
  30:          protected void Page_Load(object sender, EventArgs e)
  31:          {
  32:              if (!this.IsPostBack)
  33:              {
  34:                  this._presenter.OnViewInitialized();
  35:              }
  36:              this._presenter.OnViewLoaded();
  37:          }
  39:          #region Control Init (Unity)
  40:          protected override void OnInit(EventArgs e)
  41:          {
  42:              IUnityContainer container = Container.Instance;
  43:              _presenter = container.Resolve<IZaakDetailsPresenter>();
  44:              _presenter.View = this;
  45:              base.OnInit(e);
  46:          }
  47:          #endregion
  49:          #region IZaakDetailsView Members
  50:          public void ShowCurrentZaakOnView(Zaak zaak)
  51:          {
  52:              DetailsAlgemeenControl.CurrentZaak = zaak;
  53:              DetailsVoortgangControl.CurrentZaak = zaak;
  54:          }
  55:          #endregion
  56:      }
  57:  }

Listing 3.: The View

On line 50 of listing 3 the OnInit method of the UserControl (our view) is listed. Inside the body of this method we can see that we instantiate a variable named container (type IUnityContainer) and put a Container.Instance in it. On the next line (line 53) we fill the private member _presenter (the private member that is used in our property Presenter) by letting the container resolve the interface  IZaakDetailsPresenter. On the next line (line 54) we tell the Presenter that it’s View is this control. We have to do this here, because the View is where the request comes in. So this is the first component of our App that is loaded. Because my requirement is to create modules that can be used in Sharepoint or in ASP.NET, I cannot use the Global.asax to resolve the concrete implementations.

The ascx, or html is very straightforward, so i am not showing it, because I feel it is in the way of what i want to tell. I hope it is clear enough without it.

The Container
So how can
the container variable that is of Type IUnityContainer, an interface, on line 52 know what concrete class to Resolve? and where does Container come from. What does Container.Instance do?
In a class called container I create a UnityContainer using the Singleton design pattern:

   1:  using System;
   2:  using Microsoft.Practices.Unity;
   3:  using HC.Models;
   4:  using HC.Interfaces.Zaak;
   5:  using HC.Services;
   6:  using HC.Presenters.Zaak;
   8:  namespace HC.ZaakModule
   9:  {
  10:      public class Container
  11:      {
  13:          private static IUnityContainer instance;
  15:          private Container() { }
  17:          public static IUnityContainer Instance
  18:          {
  19:              get
  20:              {
  21:                  if (instance == null)
  22:                  {
  23:                      instance = new UnityContainer();
  25:                      instance.RegisterType<IZaakModel, ZaakModel>(new ContainerControlledLifetimeManager())
  26:                          .RegisterType<IZaakService, ZaakService>()
  27:                          .RegisterType<IZaakView, Zaken>()
  28:                          .RegisterType<IZaakPresenter, ZaakPresenter>()
  29:                          .RegisterType<IZaakListView, ZaakList>()
  30:                          .RegisterType<IZaakSearchPresenter, ZaakSearchPresenter>()
  31:                          .RegisterType<IZaakSearchView, ZaakSearch>()
  32:                          .RegisterType<IZaakListPresenter, ZaakListPresenter>()
  33:                          .RegisterType<IZaakDetailsView, ZaakDetails>()
  34:                          .RegisterType<IZaakDetailsPresenter, ZaakDetailPresenter>();
  35:                  }
  36:                  return instance;
  37:              }
  38:          }
  39:      }
  40:  }

Listing 4.: The Container


Using the singleton design pattern
the registering of the concrete implementation to the interfaces will be done only once, as you can see in the module I am building there are more components that follow the same pattern, so using a singleton was in my opinion the way to go in this case.
I choose to use a simple version of the singleton, I make a class called container, this class has a private static variable called instance (of type IUnityContainer).
The class has a private constructor, so the class cannot be directly created. Furthermore the class has a public static property (type IUnityContainer) that can only get a single instance of a IUnityContainer, because in the getter we check if the private member called instance (type IUnityContainer) is null or has been filled already, if it is filled the instance it contains is returned, but if it is null a new UnityContainer is instantiated and using a Fluent Interface all Interfaces and their concrete implementations are registered inside it before we pass it to the instance variable, after that the instance it contains is returned.

On line 25 of listing 4 the RegisterType has a parameter and the following RegisterType methods of the fluent interface have not. With new ContainerControlledLifeManager() as a parameter into the RegisterType method we tell Unity to resolve the concrete implementation as a singleton. In the case of the Model I need it to be a singleton, because the model is the only place some state need to be held in my architecture.

Configuration file
Configuring the registration in a  configuration file is also possible, in my case I did not wanted to do it, but I can understand that in some cases that is exactly what you want.

Ofcourse a lot more has to be considered when using this architecture, but I hope this article helps in understanding how you can use Dependency injection or Inversion of control and the Model view Presenter pattern to create maintainable and robust applications.

Henry Cordes
My thoughts exactly…

SDN Article on MVC Framework

Published 3/9/2009 by Henry in ASP.NET | C#
Tags: ,

My article (in dutch) with the title: ASP.NET Webapplications finally unit-testable, or (ASP.NET webapplicaties eindelijk unit-testbaar in dutch) is been published in the 100th edition of the SDN Magazine (Software Developers Network). SDN 100th Magazine in pdf format and is available for download.

VP100100th SDN Magazine

Henry Cordes
My thoughts exactly…