ProjectConfigTransformFileName - Web.Config Transformation

The Need
We start to use AppHarbor .NET PaaS to deploy our web-application.
Because we still have another instance of the same application running in shared hosting provider we needed a way to support both deployment from the same code-base.

The Problem
Visual Studio support different configuration for project out-of-the-box. The two default configurations are Debug and Release. In web projects you also have a matching web.config transformation file for each configuration, that is web.debug.config and web.release.config. Each of them contain only the parts that need to change for each configuration.
I want to have a third web.config transformation with AppHarbor specific configuration without having a new project configuration.
Visual Studio does not support this setup, but MSBuild does.

Why?
I choose not to add a new project configuration, even though it's the route Visual Studio takes you, because it will mean that our team will have one more thing to learn, one more thing to maintain and one more thing that can go wrong.

The Solution
After some digging into Microsoft.Web.Publishing.targets that is located in C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\Web in my dev machine I found the MSBuild variable name ProjectConfigTransformFileName.
Microsoft did a great job of convention over configuration with this script. The convention is to use the web.config transformation name web.[configuration].config but if you specify ProjectConfigTransformFileName it will use that one over the convention.

Since we use Jenkins as CI server we simply pass one more parameter to the MSBuild /p:ProjectConfigTransformFileName=web.release.appharbor.config and now everything works exactly the same beside the fact we use AppHarbor web.config transformation.

Continuous Delivery of ASP MVC with Jenkins and MSDeploy

We have been using Jenkins to deploy our web application for a while using continuous deployment, that is we used to push our changes into our git repository, go into Jenkins and run the deployment job.
Last month after successfully working in this way we decide we can trust ourselves and our systems and move to continuous deployment (or more accurately continuous release).

The ingredients

• Jenkins (LTS 1.509.1) with the following plugins
• Jenkins GIT plugin
• Jenkins MSBuild Plugin
• JENKINS MSTest plugin
• MSTestRunner Plugin
• CloudBees Build Flow plugin
• MSBuild
• MSTest
• MSDeploy

We divide the deployment process into several jobs and connect them all together using CloudBee Build Flow plugin.

The Jobs

1. build & test - This job build and test both debug and release configuration of our web application
2. deploy - This job deploy our web application using MSDeploy
3. end-to-end-tests - This job run end-to-end test on our production web application using Watir web testing framework
4. continuous delivery - This job is a build flow job that simply run jobs 1,2,3 in order. If anything goes wrong it notify us.

What's still missing?

1. Staging - We are working on deploy our web application into staging environment and run the end-to-end test on it. This does not guaranty success but it does catch errors. 

In the next posts I'll go into details about each of the jobs.

ASP MVC 4 with MEF 2 on .NET 4.0

ASP MVC 4 is the latest and greatest of ASP MVC framework.

Even when creating modest web applications there is a need to create well designed software so it will be testable and maintainable.

I've decide to use MEF 2 with ASP MVC 4 in order to inject any dependencies my controller have.

Currently I have only single dependency which is an EventLogger interface I use in several controllers to signal events such as user login, fail to login and other business related events.

Even though it just one dependency I know they will keep on coming so I decide to use MEF and also wanted to use the new registrations API (Convention).

The problem is that after MEF 2 Previous 4 Microsoft decide to change the minimun .NET framework version to 4.5, but my (and most) web hosting only support .NET 4.0.

I've found that I still can use the MEF 2 Preview 4 for now and upgrade as soon as my web hosting will allow to run 4.5 code.

I know it's not the ideal solution but it works and it works good.

I find MEF (Microsoft) and Guice (Google) very a like. The new MEF registration API looks very much like Guice binding API. I know Guice is "just" IoC framework and MEF is much more but for my needs I just need it as IoC for now.

So, just to share some code, when my ASP MVC application starts it invoke this method to setup the composition. This is very very simple but this is the basic on which more parts can be built.

  public class CompositionConfig {
    public static void Init() {
      RegistrationBuilder rb = new RegistrationBuilder();

      SetupParts(rb);

      // Add all controllers
      rb.ForTypesMatching(t => typeof(IController).IsAssignableFrom(t)).Export();

      var ac = new AssemblyCatalog(typeof(CompositionConfig).Assembly, rb);
      CompositionProvider.SetCatalog(ac);
    }

    private static void SetupParts(RegistrationBuilder rb) {
#if DEBUG
      rb.ForType<NoopEventLogger>().Export<EventLogger>();
#else
      rb.ForType<EmailEventLogger>().Export<EventLogger>();      
#endif
    }
  }