In MVC3 a GlobalFilterCollection has been added to the Application_Start. This allows you to register filters that will be applied to all controller actions in a single location. Also, MVC3 web applications now add an instance of HandleErrorAttribute to these GlobalFilters by default. This means that errors in the MVC pipeline will now be automatically handled by these attributes and never fire the HttpApplication's OnError event.

This is nice because it is another step away from the old ASP.NET way of doing things, and a step toward the newer cleaner MVC way of doing things.

Out With the Old

Our old HttpModule wired up to the HttpApplication's OnError event and used that to log unhandled exceptions in web applications. It didn't care if the error happened in or out of the MVC pipeline, either way it was going to bubble up and get caught in the module.

public virtual void Init(HttpApplication context)
{
   InsightManager.Current.Register();
   InsightManager.Current.Configuration.IncludePrivateInformation = true;
   context.Error += OnError;
}

private void OnError(object sender, EventArgs e)
{
   var context = HttpContext.Current;
   if (context == null)
       return;
   Exception exception = context.Server.GetLastError();
   if (exception == null)
       return;

   var abstractContext = new HttpContextWrapper(context);   InsightManager.Current.SubmitUnhandledException(exception, abstractContext);
}

However, now the MVC HandleErrorAttribute may handle exceptions right inside of the MVC pipeline, meaning that they will never reach the HttpApplication and the OnError will never be fired. What to do, what to do...

In With the New

Now we need to work with both the attributes and the HttpApplication, ensuring that we will catch errors from both inside and outside of the MVC pipeline. This means that we need to find and wrap any instances of HandleErrorAttribute in the GlobalFilters, and still register our model to receive notifications from the HttpApplications OnError event.

The first thing we had to do was create a new HandleErrorAttribute. Please note that this example is simplified and only overrides the OnException method. If you want to do this "right", you'll have to override and wrap all of the virtual methods in HandleErrorAttribute.

public class HandleErrorAndReportToInsightAttribute : HandleErrorAttribute
{
   public bool HasWrappedHandler
   {
       get { return WrappedHandler != null; }
   }

   public HandleErrorAttribute WrappedHandler { get; set; }
   public override void OnException(ExceptionContext filterContext)
   {
       if (HasWrappedHandler)
           WrappedHandler.OnException(filterContext);
       else
           base.OnException(filterContext);
       if (filterContext.ExceptionHandled)           InsightManager.Current.SubmitUnhandledException(filterContext.Exception, filterContext.HttpContext);   }
}

Next we needed to update our HttpModule to find, wrap, and replace any instances of HandleErrorAttribute in the GlobalFilters.

public virtual void Init(HttpApplication context)
{
   InsightManager.Current.Register();
   InsightManager.Current.Configuration.IncludePrivateInformation = true;
   context.Error += OnError;
   ReplaceErrorHandler();
}

private void ReplaceErrorHandler()
{
   var filter = GlobalFilters.Filters.FirstOrDefault(f => f.Instance is HandleErrorAttribute);
   var handler = new HandleErrorAndReportToInsightAttribute();
   if (filter != null)
   {
       GlobalFilters.Filters.Remove(filter.Instance);
       handler.WrappedHandler = (HandleErrorAttribute) filter.Instance;
   }
   GlobalFilters.Filters.Add(handler);
}

In Conclusion
Now when we register the InsightModule in our web.config, we will start capturing all unhandled exceptions again.

<configuration>
 <configSections>
   <section name="codesmith.insight" type="CodeSmith.Insight.Client.Configuration.InsightSection, CodeSmith.Insight.Client.Mvc3" />
 </configSections>
 <codesmith.insight apiKey="XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX" serverUrl="http://app.codesmithinsight.com/" />
 <system.web>
   <customErrors mode="On" />
   <httpModules>
     <add name="InsightModule" type="CodeSmith.Insight.Client.Web.InsightModule, CodeSmith.Insight.Client.Mvc3"/>
   </httpModules>
 </system.web>
</configuration>

So, what else is new in MVC 3?

MVC 3 now has a GlobalFilterCollection that is automatically populated with a HandleErrorAttribute. This default FilterAttribute brings with it a new way of handling errors in your web applications. In short, you can now handle errors inside of the MVC pipeline.

What does that mean?

This gives you direct programmatic control over handling your 500 errors in the same way that ASP.NET and CustomErrors give you configurable control of handling your HTTP error codes.

How does that work out?
Think of it as a routing table specifically for your Exceptions, it's pretty sweet!

Global Filters

The new Global.asax file now has a RegisterGlobalFilters method that is used to add filters to the new GlobalFilterCollection, statically located at System.Web.Mvc.GlobalFilter.Filters. By default this method adds one filter, the HandleErrorAttribute.

public class MvcApplication : System.Web.HttpApplication
{
    public static void RegisterGlobalFilters(GlobalFilterCollection filters)
    {
        filters.Add(new HandleErrorAttribute());
    }

HandleErrorAttributes

The HandleErrorAttribute is pretty simple in concept: MVC has already adjusted us to using Filter attributes for our AcceptVerbs and RequiresAuthorization, now we are going to use them for (as the name implies) error handling, and we are going to do so on a (also as the name implies) global scale.

The HandleErrorAttribute has properties for ExceptionType, View, and Master. The ExceptionType allows you to specify what exception that attribute should handle. The View allows you to specify which error view (page) you want it to redirect to. Last but not least, the Master allows you to control which master page (or as Razor refers to them, Layout) you want to render with, even if that means overriding the default layout specified in the view itself.

public class MvcApplication : System.Web.HttpApplication
{
    public static void RegisterGlobalFilters(GlobalFilterCollection filters)
    {
        filters.Add(new HandleErrorAttribute
        {
            ExceptionType = typeof(DbException),
            // DbError.cshtml is a view in the Shared folder.
            View = "DbError",
            Order = 2
        });
        filters.Add(new HandleErrorAttribute());
    }Error Views

All of your views still work like they did in the previous version of MVC (except of course that they can now use the Razor engine). However, a view that is used to render an error can not have a specified model! This is because they already have a model, and that is System.Web.Mvc.HandleErrorInfo

@model System.Web.Mvc.HandleErrorInfo          
@{
    ViewBag.Title = "DbError";
}

<h2>A Database Error Has Occurred</h2>

@if (Model != null)
{
    <p>@Model.Exception.GetType().Name<br />
    thrown in @Model.ControllerName @Model.ActionName</p>
}Errors Outside of the MVC Pipeline

The HandleErrorAttribute will only handle errors that happen inside of the MVC pipeline, better known as 500 errors. Errors outside of the MVC pipeline are still handled the way they have always been with ASP.NET. You turn on custom errors, specify error codes and paths to error pages, etc.

It is important to remember that these will happen for anything and everything outside of what the HandleErrorAttribute handles. Also, these will happen whenever an error is not handled with the HandleErrorAttribute from inside of the pipeline.

<system.web>
  <customErrors mode="On" defaultRedirect="~/error">
    <error statusCode="404" redirect="~/error/notfound"></error>
  </customErrors>Sample Controllers
public class ExampleController : Controller
{
    public ActionResult Exception()
    {
        throw new ArgumentNullException();
    }
    public ActionResult Db()
    {
        // Inherits from DbException
        throw new MyDbException();
    }
}

public class ErrorController : Controller
{
    public ActionResult Index()
    {
        return View();
    }
    public ActionResult NotFound()
    {
        return View();
    }
}

Putting It All Together

If we have all the code above included in our MVC 3 project, here is how the following scenario's will play out:

1.       A controller action throws an Exception.
You will remain on the current page and the global HandleErrorAttributes will render the Error view.

2.       A controller action throws any type of DbException. You will remain on the current page and the global HandleErrorAttributes will render the DbError view.

3.       Go to a non-existent page.
You will be redirect to the Error controller's NotFound action by the CustomErrors configuration for HTTP StatusCode 404.

But don't take my word for it, download the sample project and try it yourself.

Three Important Lessons Learned

For the most part this is all pretty straight forward, but there are a few gotcha's that you should remember to watch out for:

1) Error views have models, but they must be of type HandleErrorInfo.
It is confusing at first to think that you can't control the M in an MVC page, but it's for a good reason. Errors can come from any action in any controller, and no redirect is taking place, so the view engine is just going to render an error view with the only data it has: The HandleError Info model. Do not try to set the model on your error page or pass in a different object through a controller action, it will just blow up and cause a second exception after your first exception!

2) When the HandleErrorAttribute renders a page, it does not pass through a controller or an action.
The standard web.config CustomErrors literally redirect a failed request to a new page. The HandleErrorAttribute is just rendering a view, so it is not going to pass through a controller action. But that's ok! Remember, a controller's job is to get the model for a view, but an error already has a model ready to give to the view, thus there is no need to pass through a controller.

That being said, the normal ASP.NET custom errors still need to route through controllers. So if you want to share an error page between the HandleErrorAttribute and your web.config redirects, you will need to create a controller action and route for it. But then when you render that error view from your action, you can only use the HandlerErrorInfo model or ViewData dictionary to populate your page.

3) The HandleErrorAttribute obeys if CustomErrors are on or off, but does not use their redirects.
If you turn CustomErrors off in your web.config, the HandleErrorAttributes will stop handling errors. However, that is the only configuration these two mechanisms share. The HandleErrorAttribute will not use your defaultRedirect property, or any other errors registered with customer errors.

In Summary

The HandleErrorAttribute is for displaying 500 errors that were caused by exceptions inside of the MVC pipeline. The custom errors are for redirecting from error pages caused by other HTTP codes.

ASP.NET MVC 3 introduces two new interfaces to allow simple integration of IoC containers into the MVC pipeline, allowing many different types to be resolved using your IoC container of choice. These interfaces are IDependencyResolver and IControllerActivator but before you go ahead and implement both, let's take a look at whether they are both actually needed.

First some background

If you wanted to inject dependencies into your controllers in ASP.NET MVC 2, you were required to either implement IControllerFactory or subclass DefaultControllerFactory. Typically, you would pass your IoC container into the constructor of your custom controller factory and use it to resolve the controller in the CreateController method. You may also have added custom code in ReleaseController to clean up dependencies

This worked reasonably well, but in ASP.NET MVC 3 things have changed so we can use DI for a whole host of other objects such as filters and view engines

The new interface that we should implement is IDependencyResolver:

The important thing about your implementation of this interface is that it should return null if it cannot resolve a particular object. Below is a simple implementation using Unity:


When an MVC application starts for the first time, the dependency resolver is called with the following types in the following order:
- IControllerFactory
- IControllerActivator
- HomeController
….

If you do not implement IControllerFactory or IControllerActivator, then the MVC framework will try to get the controller from the DependencyResolver itself. As a side note, there is no need to worry about performance (regarding so many calls to the resolver) because MVC will only try to resolve theIControllerFactory and IControllerActivator once on startup and if no implementations are registered then it will subsequently always query the DependencyResolver first

The MVC framework goes on to try to resolve many other types which you probably have not implemented or registered with your IoC container, but as long as your dependency resolver returns null if the type is not registered, MVC will default back to the built-in implementations

If you did not implement your resolver to return null if a type is not registered then you will probably end up seeing an error similar to:

The current type, System.Web.Mvc.IControllerFactory, is an interface and cannot be constructed

The other important thing to note is that both methods on this interface take in the actual service type. This typically means that when you register your controllers with your IoC container, you should only specify the concrete type, not the IController, interface

i.e. using Unity as an example:


rather than:


Failing to register your controllers conrrectly and you will see

No parameterless constructor defined for this object

So at this stage, we have an implementation of IDependencyResolver and nothing else and yet our controller are all resolving correctly. It makes you wonder about whether IControllerActivator is really needed...

About IControllerActivator

IControllerActivator was introduced with ASP.NET MVC 3 to split the functionality of the MVC 2 controller factory into two distinct classes. As far as we can tell, this was done to adhere to the Single Responsibility Principle (SRP). So now in MVC 3, the DefaultControllerFactory outsources the responsibility of actually instantiating the controller to the controller activator. The single method interface is shown below:


If you implement this interface and register your activator with your IoC container, the MVC framework will pick it up and use it when trying to instantiate controllers, but you have to wonder why you would do this instead of just letting your dependency resolver do it directly. Brad Wilson to the rescue:

"If your container can build arbitrary types, you don't need to write activators. The activator services are there for containers that can't be arbitrary types. MEF can't, but you can add [Export] attributes to your controllers to allow MEF to build them..."

This means that if you are working with any competent IoC container* (Castle Windor, Unity, Ninject, StructureMap, Autofac et al), IControllerActivator is not needed and offers no benefit over allowing your DependencyResolver to instantiate your controllers.

* (With the exception of MEF which isn't an IoC container any way)

So we now know that we are probably not required to implement this interface, but are there any benefits to doing so? Something that we have seen mentioned (we cannot remember where) is that implementing IControllerActivator allows you you can provide a more meaningful error message if resolution fails. It is true that the message you would get otherwise (No parameterless constructor defined for this object) is not 100% clear, but we are not sure that this justifies another class just for this purpose. Surely, once you have seen this message, the next time you encounter, it you will immediately know what the problem is. Even if you do implement IControllerActivator, you will not have access to the (normally) detailed message that you IoC container provides when resolution fails, so you can do little more than say resolution failed - i don't know why.

Conclusion

So, should you implement IControllerActivator? Probably not. If you are using pretty much any well known IoC container, just implement IDependencyResolver and it will do everything for you. There is also no need for a custom implementation of IControllerFactory. If you are worried about the lack of release method on the dependency resolver, don't be. The worst case scenario requires a small change to the way that you are using your IoC container. Next time we will talk about how to make sure your dependency resolver plays nicely with IDisposable

Today, we found a good answer on syntax highlighting for Razor. In the Visual Studio Gallery located at http://visualstudiogallery.msdn.microsoft.com/en-us/8dc77b9c-7c83-4392-9c46-fd15f3927a2e, a new Visual Studio extension has been recently added for a “Razor Syntax Highlighter”.



To leverage this new extension, we had to remove the editor mapping for .cshtml files in the Visual Studio Text Editor/File Extensions window and install the highlighter extension. As you see in the figure below, it worked great. This new extension uses the Razor Parser libraries to appropriately highlight the Razor code.

Figure 1 - Syntax Highlighting Visual studio 2010 Add-on

Unfortunately, this feature is offered as a Visual Studio Extension and hence is only available for paid-for Visual Studio 2010 editions.

Looking at the Razor Syntax, one can summarize it as a means to short-hand the <%= %> used in ASPX pages to designate code sections. For Razor, only a simple @ sign is used in-place of that bulky aforementioned code markup . Additionally, the Razor parser introduces helpful intelligence that makes the syntax even more user-friendly. For instance the following is a code block you would see in an ASPX page:

<%=if(true){%>
       <input type="hidden" value="istrue"/>
<%}%>  

The corresponding Razor block for this snippet would be:

@if(true){
       <input type="hidden" value="istrue"/>
}

The Razor syntax has simply “inferred” that the code will have a closing curly bracket without us having to apply any special markup tags to it. This further reduces the markup needed to accomplish the same task.

An important difference between Razor and ASPX View Engines is the absence of master pages for the earlier. Razor simply provides a _ViewStart.cshtml to bootstrap our application layout.

@{
    Layout = "~/Views/Shared/_Layout.cshtml";
}

Latest Razor Beta does however support Partial rendering (RenderPartial) to explicitly render a Partial View as well as calling @RenderBody() which loads the actual view content to be served.

Next, we will be talking about creating an MVC project with dual support for ASPX/Razor View Engines as well as further explore the Razor syntax.

Overview

Services exist in order to serve external clients. They do so by exposing a wide range of external interfaces which are later used by the clients to interact with the service.

After initial deployment, and potentially several times during their lifetime, services may need to be changed for a variety of reasons, such as changing business needs, re-factorization of code, or to address other issues.

Each change introduces a new version of the service. Each new service version potentially introduces changes to the external interfaces exposed by the service.

Our goal, as developers, is to be able to freely change our service internals (and sometimes, when needed, external interfaces), and on the same time, allow existing and new clients to keep using the service.

In order to do so, we need to form a set of versioning guidelines.

This article will cover basic concepts related to versioning issues and will provide a set of guidelines which aim to provide a simple solution for the versioning problem domain.

All the information exists freely on the Internet. We didn’t invent anything new. We just gathered most of the information in one simple blog post, for your convenience.

A lot of the guidelines below were taken from an excellent set of MSDN articles:

http://msdn.microsoft.com/en-us/library/ms731060.aspx and http://msdn.microsoft.com/en-us/library/ms733832.aspx. These articles are very good reading material.  


Reduce the Problem Domain

Services interact with external services in many different ways. They can use WCF to send and receive information. They can connect to external databases directly (by using ADO.NET, for example) and many more.

Instead of forming a set of guidelines for each protocol, the simplest way is to reduce the problem domain to one protocol and use only one set of guidelines for this protocol.

For example, instead of connecting to a database directly, it is possible to create an abstraction layer on top of the database, which will expose WCF interface to the clients. This layer will be upgraded together with the database, creating a coupling between this layer and the database. The exposed WCF interface will follow the versioning guidelines that we will mention later, thus keeping all the clients compatible with the database service, even when it is being upgraded.

To sum it up, if you like the WCF versioning guidelines that we’ll mention later on, use WCF interfaces whenever possible to expose your service functionality.  


Versioning Terminology

Strict Versioning – In many scenarios when a change is required to an external interface, the service developer does not have control over the clients and therefore cannot make assumptions about how they would react to changes in the message XML or schema. The recommended approach in such scenarios is to treat existing data contracts as immutable and create new data contracts (with unique XML qualified names) instead.

Lax Versioning – In many other scenarios, the service developer can make the assumption that adding a new, optional member to the data contract will not break existing clients. This requires the service developer to investigate whether existing clients are not performing schema validation and that they ignore unknown data members. In these scenarios, it is possible to take advantage of data contract features for adding new members in a non-breaking way. WCF support Lax versioning: that is, they do not throw exceptions for new unknown data members in received data, unless requested otherwise.

When a connection is made between a client and a server of a different version, and a strict versioning is used, the client won’t be able to connect to a service of a different version. When lax versioning is used, the client will be able to connect and it is up to the developer to handle backward and forward compatibility.  


Client\Server Paradigm

In a client\server world, a client sends requests to a server, which, in turn, responds back to the client.

When versioning is introduced into the system, we may encounter the following scenarios:

Client and server use the same version.
Client is older than the server.
Client is newer than the server.

Each scenario should be handled separately, but there is one rule which applies to all: Newer element knows more than older element, therefore, newer elements should be the more proactive elements in the versioning game.

This means the following:

Client and server use the same version – No problem here. Communication will work as expected.

Client is older than the server – The server should support both older and current clients. When Lax Versioning is used, the server is allowed to add new data members and new operations (according to Lax guidelines which will be described later on). It must expose the same WCF service, on the same contract with the same name and namespace. When Strict Versioning is used, the server must expose (at least) two WCF services (and WCF contracts). The first is the new WCF service, on the new contract with a new namespace and name, and the rest are all the supported old WCF services with their original contacts, namespaces and names.

Client is newer than the server – The client must avoid using unsupported operations on an older server. When Lax versioning is used, the client is not allowed to call new operations (which don’t exist on the server side). When Strict versioning is used, the client must use a WCF endpoint which exposes a contract matching the one used by the server. In both approaches, the client must know the version of the server. This is performed by some kind a version discovery mechanism (more on this below).  

Note – If an element acts both as a client and as a server, it is very reasonable that it would suffer from both issues above, during the upgrade period. This means that it will probably have a local client newer than a remote server and a local server newer than a remote client. In these situations, each direction should be handled separately.    


Version Discovery Basics

When a client is newer than the server, as we already know, it must protect itself when communicating with an older server.

For example, if Lax versioning is used, the client should be responsible not to call new operations which are not supported by the server.

When Strict versioning is used, it should find a matching contract, support by the server, to communicate on.

In order to do that, the client must discover the server’s version. This is called Version Discovery.

There are several ways to discover the server’s version:

Get Version API – The server should expose its version somehow. The client should use this API to discover the server’s version before attempting to communicate with the server.

Fallback – The client tries to communicate with the server with the newest contract version known to the client, and falls back to older versions when the communication fails until it finds a contract version match (of course, this can only work with Strict versioning).

Configuration – The server version is stored somewhere in local configuration and the client can read it before attempting to connect to the server.   


Versioning Guidelines

So far we had a long introduction to the versioning world. It’s time to actually discuss some actual versioning guidelines.

First we will try to understand when to use Lax versioning and when to use Strict versioning. Later on, we will provide a set of guidelines for each versioning schema.

When building a complex system, involving multiple machines working together to expose one big external service, we can distinguish between two types of communication flows, inner communication an external communication.

Inner Communication – This covers all communication flows between the system’s machines. In such systems, usually, the developers have control on all components involved in the communication flows. Therefore, the natural versioning schema should be Lax versioning. As a reminder, Lax versioning can be used when we know something about the involved components and can enforce several assumptions on them. Of course, if we can’t make these assumptions, or if we require huge contract changes which can’t be covered by the Lax versioning guidelines (which will be covered later on), we can always fallback to Strict versioning.

External Communication – This covers all communication between internal endpoints (controlled by the system developers) to external endpoints (not controlled by the system developers, naturally). Since we don’t control one side of the conversation, Strict versioning is the only way to go. This means that whenever a new version is available, we create a new contract to represent it, while keeping the old contract intact. We must publish both the new contract and the old contract (or contracts, if we want to support several versions back) simultaneously. We might also consider providing some assistance in terms of providing some version discovery mechanisms. If clients are newer than the server, they will have to use one of the version discovery mechanisms to survive.   


Lax Versioning Guidelines

The guidelines are divided to service contract guidelines and data contract guidelines.

Lax Service Contract:

Namespace and Name – DO NOT change namespace or name between versions. Do not add namespace or name, if the contract didn’t have namespace or name in the previous version (unless you want to add the default namespace and name)

Operations Addition – Adding service operations exposed by the service can be considered as a non-breaking change because existing (older) clients need not be concerned about those new operations. Newer clients must use version discovery methods before contacting an older server and avoid calling new operations. If version discovery is impossible, adding operations is considered as a breaking change (strict).

Operations Removal – Removing operations is considered to be a breaking change and therefore, NOT ALLOWED. To make such a change, strict versioning should be used (define a new service contract and expose it on a new endpoint). It is still possible to remove operations, but this can be performed only after the versioning difference between a client and a server exceeds the maximum allowed by the system (for example, we support only one version back and we now upgrade to version N+2).

Operation Parameters Types – Changing parameter types or return types generally is considered to be a breaking change unless the new type implements the same data contract implemented by the old type. Other type changes are NOT ALLOWED. To make such changes, add a new operation to the service contract or use strict versioning.

Operation Parameters Addition/Removal – Adding or removing an operation parameter is a breaking change, therefore, it is NOT ALLOWED. To make such a change, add a new operation to the service contract or use strict versioning.

Operation Parameters Aggregation – It is recommended to use one aggregated data contract as an operation parameter, rather than separate multiple parameters. By using a data contract as aggregated parameter, while keeping the Lax guidelines for data contracts (see below), it is easier to keep an operation backward compatible. It is possible to change internal parameters without being limited to the above restrictions.

Fault Contracts – The list of faults described in a service’s contract is not considered exhaustive. At any time, an operation may return faults that are not described in its contract. Therefore changing the set of faults described in the contract is not considered a breaking change. For example, adding a new fault to the contract using the FaultContractAttribute or removing an existing fault from the contract is allowed.

Lax Data Contract:

Namespace and Name – DO NOT change namespace or name between versions. Do not add namespace or name, if the contract didn’t have namespace or name in the previous version (unless you want to add the default namespace and name)

Data Contract Names - In later versions, DO NOT change the data contract name or namespace. If changing the name or namespace of the type underlying the data contract, be sure to preserve the data contract name and namespace by using the appropriate mechanisms, such as the Name property of the DataContractAttribute.

Data Members Names – In later versions, DO NOT change the names of any data members. If changing the name of the field, property, or event underlying the data member, use the Name property of the DataMemberAttribute to preserve the existing data member name.

Data Members Types – In later versions, DO NOT change the type of any field, property, or event underlying a data member such that the resulting data contract for that data member changes. Keep in mind that interface types are equivalent to Object for the purposes of determining the expected data contract.

Data Members Addition – In later versions, new data members can be added. They should always follow these rules:

a. The IsRequired property should always be left at its default value of false.
b. If a default value of null or zero for the member is unacceptable, a callback method should be provided using the OnDeserializingAttribute to provide a reasonable default in case the member is not present in the incoming stream.
c. The Order property on the DataMemberAttribute should be used to make sure that all of the newly added data members appear after the existing data members. The recommended way of doing this is as follows: None of the data members in the first version of the data contract should have their Order property set. All of the data members added in version 2 of the data contract should have their Order property set to 2. All of the data members added in version 3 of the data contract should have their Order set to 3, and so on. It is permissible to have more than one data member set to the same Order number.

Data Members Order – In later versions, DO NOT change the order of the existing data members by adjusting the Order property of the DataMemberAttribute attribute.

Data Members Removal – DO NOT remove data members in later versions, even if the IsRequired property was left at its default property of false in prior versions.

Data Members IsRequired –
a. DO NOT change the IsRequired property on any existing data members from version to version.
b. For required data members (where IsRequired is true), DO NOT change the EmitDefaultValue property from version to version.

Branching – DO NOT attempt to create branched versioning hierarchies. That is, there should always be a path in at least one direction from any version to any other version using only the changes permitted by these guidelines. For example, if version 1 of a Person data contract contains only the Name data member, you should not create version 2a of the contract adding only the Age member and version 2b adding only the Address member. Going from 2a to 2b would involve removing Age and adding Address; Going in the other direction would entail removing Address and adding Age. Removing members is not permitted by these guidelines.

Known Types – You should generally not create new subtypes of existing data contract types in a new version of your application. Likewise, you should not create new data contracts that are used in place of data members declared as Object or as interface types. For example, in version 1 of your application, you may have the LibraryItem data contract type with the Book and Newspaper data contract subtypes. LibraryItem would then have a known types list that contains Book and Newspaper. Suppose you now add a Magazine type in version 2 which is a subtype of LibraryItem. If you send a Magazine instance from version 2 to version 1, the Magazine data contract is not found in the list of known types and an exception is thrown. Creating these new classes is allowed only when you know that you can add the new types to the known types list of all instances of your old application or if newer instances use version discovery and will not send new types to an old server.

Enumerations – DO NOT add or remove enumeration members between versions. You should also not rename enumeration members; unless you use the Name property on the EnumMemberAttribute attribute to keep their names in the data contract model the same.

Inheritance –

DO NOT attempt to version data contracts by type inheritance. To create later versions, either change the data contract on an existing type (Lax) or create a new unrelated type (Strict).

The use of inheritance together with data contracts is allowed, provided that inheritance is not used as a versioning mechanism and that certain rules are followed. If a type derives from a certain base type, do not make it derive from a different base type in a future version (unless it has the same data contract). There is one exception to this: you can insert a type into the hierarchy between a data contract type and its base type, but only if it does not contain data members with the same names as other members in any possible versions of the other types in the hierarchy. In general, using data members with the same names at different levels of the same inheritance hierarchy can lead to serious versioning problems and therefore, it is prohibited.

Collections – Collections are interchangeable in the data contract model. This allows for a great degree of flexibility. However, make sure that you do not inadvertently change a collection type in a non-interchangeable way from version to version. For example, do not change from a non-customized collection (that is, without the CollectionDataContractAttribute attribute) to a customized one or a customized collection to a non-customized one. Also, do not change the properties on the CollectionDataContractAttribute from version to version. The only allowed change is adding a Name or Namespace property if the underlying collection type’s name or namespace has changed and you need to make its data contract name and namespace the same as in a previous version.

Round Tripping – In some scenarios, there is a need to “round-trip” unknown data that comes from members added in a new version. For example, a “versionNew” service sends data with some newly added members to a “versionOld” client. The client ignores the newly added members when processing the message, but it resends that same data, including the newly added members, back to the versionNew service. The typical scenario for this is data updates where data is retrieved from the service, changed, and returned. If the data contract is expected to be used in a round tripping scenario, then starting with the first version of a data contract, always implement IExtensibleDataObject to enable round-tripping. If you have released one or more versions of a type without implementing this interface, it is usually recommended to implement it in the next version of the type.  


Strict Versioning Guidelines

Strict versioning guidelines are also divided into service contract and data contract guidelines, although they are very similar.

Strict Service Contract:

Namespace and Name – At least one of the namespace or name MUST be changed in later version, in order to break the contract compatibility. If the contract didn’t have namespace or name in previous version, namespace and name must be added to the contract (and must have different values than the default values)

Cascading Break – If a service contract exposes a data contract directly or via operations parameters or return value, and this data contract compatibility is broken (namespace or name replaced), then the service is also broken and MUST be treated as such, thus, a new contract should be created.

Immutability – When breaking a service contract, a new service contract MUST be created with a unique Namespace and Name, while the old contract MUST be kept intact and treated as immutable.

Strict Data Contract:

Namespace and Name – At least one of the namespace or name MUST be changed in later version, in order to break the contract compatibility. If the contract didn’t have namespace or name in previous version, namespace and name MUST be added to the contract (and must have different values than the default values)

Immutability – When breaking a data contract, a new data contract MUST be created with a unique Namespace and Name, while the old contract MUST be kept intact and treated as immutable.

Cascading Break – If a data contract is contained in a different data contract or exposed by a service contract directly or indirectly, and this data contract compatibility is broken (namespace or name replaced), then all contracts containing or exposing this data contract MUST be broken as well

For past couple of days we were checking out features of the new ASP.NET MVC Preview 3.There are couple of interesting new additions like integration with the new Razor viewengine,improvements in Model Validation,AJAX support and Dependency Injection. In this post we will discuss on, how ASP.NET MVC 3 has streamlined the ability to register/retrieve objects/services in a loosely coupled manner by incorporating support for the Common Service Locator framework.

What is Common Service Locator?Today we have many Inversion of Control/Dependency Injection Containers like NInject,StructureMap,Unity,.. etc in the .NET world.Most of these vary quite widely in terms of configuration and initialization/registration of the instances.But they provide more or less similar interface while resolving the dependencies and returning object instances.Common Service Locator framework extracts these commonalities out and provides an abstraction on top of these IoC/DI containers.This is now part of the Enterprise Library 5.0 and used in the Enterprise Library code to create/retrieve objects.Common Service Locator provides an interface IServiceLocator

It is quite evident from the method signatures that these are only related to retrieval of right object instances with proper resolution of the dependencies based upon different parameters.

Another important class related to the Common Service Locator is the ActivationException which needs to be thrown whenever there is exception in instantiating the objects /resolving the dependencies.

We were planning to use StructureMap as the DI Container and a StructureMap Adapter for Service Locator was available in Codeplex but that seemed far from complete.

So we went ahead to write few lines of code and develop a service locator which will use StructureMap as the DI container as shown below:

This class accepts an instance of the StructureMap.Container in the constructor and uses it to resolve dependencies and instantiate objects.In the implementation of the IServiceLocator methods we have to just map them suitably to StructureMap.Container.GetAllInstances and StructureMap.Container.GetInstance methods (and their overloads).The code which depends on IServiceLocator will perform exception handling based on ActivationException class whereas StructureMap raises StructureMap.StructureMapException in most of the cases.So we need to catch StructureMapException in this class and throw a ActivationException.The complete code is given below:

So we have our Service Locator class ready.In next part of the post we will see how we can plug this into the ASP.NET MVC 3.0 Framework

Introduction

One of the new features in ASP.NET MVC 3 is the ability to register a service locator that will be used by the framework. Prior versions of the MVC framework have offered opportunities for introducing concepts like service location and dependency injection (DI); in MVC 3, we have formalized the process and opened up several new opportunities for developers

This first post in the series will discuss the general strategy for service location in MVC 3. Later posts will discuss specific ways to perform service location and DI with existing and new features



Disclaimer

This blog post talks about ASP.NET MVC 3 Preview 1, which is a pre-release version. Specific technical details may change before the final release of MVC 3. This release is designed to elicit feedback on features with enough time to make meaningful changes before MVC 3 ships


General Strategy

The most important part of the strategy with service location is that it's going to be optional. This means that if you are not interested in working with a service locator, you won't be forced to. We will always offer a way to perform customization functions without requiring you to employ a service locator. We will also work to preserve backward compatibility as much as possible when introducing new service location capability into existing features of MVC

When using the registered service locator, MVC will generally employ one of three strategies, depending on the kind of work it's trying to do

1. Locating a singly registered service

There are several services which MVC uses today which have the ability to register a single instance of such a service. One example is the controller factory, which implements IControllerFactory. There is a single controller factory that's used for the entire application

When MVC attempts to use a singly registered service, it will first ask the service locator whether it has an instance of that service available. If it does, then MVC will use that; if it does not, then it will fall back to the singleton registration that's available for non-service locator users

The upside of this means that service locator users won't be required to fill their locator/container with all the existing default services used by MVC, because it will automatically fall back to these defaults when nothing exists in the locator. The potential downside of this means that it is theoretically possible to register a custom service in both places, but only the one in the locator will be used

2. Locating a multiply registered service

There are several services which MVC uses today which have the ability to register multiple instances of such a service. One example of this is the view engine, which implements IViewEngine. Typically, MVC offers a registration point which acts like a list of such services, and also offers an API which acts as a facade and figures out the appropriate way to do the work. In the case of view engines, this facade (ViewEngines.Engines) takes the form of "go to each view engine on the list and ask it for a view until one of them can provide it". There are also multiply registered services where the facade uses all the services (ModelValidatorProviders.Providers) and aggregates all the responses together

When MVC attempts to use a multiply registered service, it will continue to ask the collection facade to do the work. The collection facade will use both the statically registered instances of the service as well as any of the instances registered with the service locator, and combines them together in the way that is most appropriate for the facade. Where service order is important (as with view engines, for example), this usually means that the service locator instances will come before the statically registered instances

Like the single registration strategy, the upside of this means that service locator users won't be required to fill their locator/container with the existing default service instances. The potential downside of this is that most containers don't offer a native ordering function for multi-registration of services, so where ordering is important, it may be necessary to use the non-service locator APIs. In practice, however, it probably won't be much of an issue, as most applications don't generally need to rely on ordering (for example, they will only primarily use a single view engine), especially since service locator services generally go before the existing pre-registered services

3. Creating arbitrary objects

The final way that MVC may use a service locator is in the creation of arbitrary objects. (This is where we stray from the strictly service location functionality and use it more like a dependency injection container.) Where we've found it appropriate that an object we create may be in need of dependency injection of services, we will attempt to create that object through the service locator. One example is controller objects, which may want to take service dependencies to do their work

When MVC attempts to create an arbitrary object in this way, it will ask the service locator to create the object on its behalf. If the service locator cannot fulfill this object creation, it will generally fall back to the existing behavior in prior versions of MVC 2; usually, this means calling Activator.CreateInstance


IMvcServiceLocator and MvcServiceLocator

To enable service location in MVC, we've introduced a new interface (IMvcServiceLocator) and a new static singleton registration class (MvcServiceLocator). For Preview 1, we have also replicated the existing Common Service Locator interface (IServiceLocator) and exception class (ActivationException) in the System.Web.Mvc namespace

public interface IServiceLocator : IServiceProvider { 
    IEnumerable<TService> GetAllInstances<TService>(); 
    IEnumerable<object> GetAllInstances(Type serviceType); 
    TService GetInstance<TService>(); 
    TService GetInstance<TService>(string key); 
    object GetInstance(Type serviceType); 
    object GetInstance(Type serviceType, string key);
}   
public interface IMvcServiceLocator : IServiceLocator { 
    void Release(object instance);
}   
public static class MvcServiceLocator { 
    public static IMvcServiceLocator Current { get; } 
    public static IMvcServiceLocator Default { get; } 
    public static void SetCurrent(IServiceLocator locator);

The registration point is MvcServiceLocator.SetCurrent(), and only requires the service locator to support IServiceLocator. However, you'll notice that MvcServiceLocator.Current always returns an implementation of IMvcServiceLocator. We will automatically create the implementation of IMvcServiceLocator.Release() if one does not exist, which will call Dispose on the object if it implements Idisposable

It's also worth noting that there will always be a service locator available, even if you've never registered one. Our default service locator is not a full fledged service locator, as it only calls Activator.CreateInstance and offers no registration system. It is not meant to be a replacement for a real service locator or dependency injection container


No Configuration

MVC's usage of service location is limited to retrieving services. MVC has no need to configure the existing service locator. As such, we have made no effort to hide the configuration/registration process inherent to existing service locators or DI containers

We feel that most people will choose the container they want to use based on its registration and configuration APIs, so attempting to hide them would be counter productive


Complex Dependency Injection Needs

Razor is the new view engine that is available for ASP.NET MVC 3 Beta. Razor has directives that are the same as the WebForms view engine, so you can define namespaces at the top of the Razor file so you don’t have to use the fully qualified name when referencing objects. One of the keywords available is the new @model keyword. This keyword defines the model that is being used in the view. By default the default value is dynamic, which means you’re using a dynamic model for your view. However you can change this so you can use a strongly typed view. This article will demonstrate how to use both



Before moving on, you need to download ASP.NET MVC 3 Beta and NuPack. Click here to download and install them using the Microsoft Web Platform Installer.

Open studio 2010 and create a new ASP.NET MVC 3 Web Application (Razor) project. The new MVC 3 Beta dialog can be seen below



Choose Razor as the view engine and click OK

We’re going to add a model called FavouriteGivenName which will store the most popular given names in Australia for 2009. We’re going to add a new controller named MostPopular and add the following code:

private readonly List<FavouriteGivenName> _mostPopular = null;
        public MostPopularController()
        {
            _mostPopular = new List<FavouriteGivenName>()
                {
                    new FavouriteGivenName() {Name = "Jack"},
                    new FavouriteGivenName() {Name = "Riley"},
                    new FavouriteGivenName() {Name = "William"},
                    new FavouriteGivenName() {Name = "Oliver"},
                    new FavouriteGivenName() {Name = "Lachlan"},
                    new FavouriteGivenName() {Name = "Thomas"},
                    new FavouriteGivenName() {Name = "Joshua"},
                    new FavouriteGivenName() {Name = "James"},
                    new FavouriteGivenName() {Name = "Liam"},
                    new FavouriteGivenName() {Name = "Max"}
                };
        }

        public ActionResult DynamicView()
        {
            return View(_mostPopular);
        }

We’ll add a new view, but we won’t select Create a strongly-typed view



Upon completion the view’s HTML is the following

@model dynamic
@{
    View.Title = "DynamicView";
    Layout = "~/Views/Shared/_LayoutPage.cshtml";
}

<h2>Dynamic View</h2>

You’ll notice in the code above, the first line contains the @model keyword and it’s dynamic.

@model dynamic

This means you won’t have access to a strongly-typed object when you code this view. You can use the following code to render the popular names to the view.

@model dynamic
@{

    View.Title = "DynamicView";

    Layout = "~/Views/Shared/_LayoutPage.cshtml";

}

<h2>Dynamic View</h2>

<p>
      @foreach(var givenName in Model) {

            @givenName.Name <br />

      }

</p>

On the other hand you wanted a strong-typed view and not rely on dynamic views, it’s easy. Add another action and create a new view, but this time select Create a strongly-typed view



By default you’ll now have a strongly typed view as shown in the code snippet below

@model IEnumerable<MvcApplication5.Models.FavouriteGivenName>

@{

    View.Title = "StronglyTypedView";

    Layout = "~/Views/Shared/_LayoutPage.cshtml";

}

<h2>Strongly Typed View</h2>

Now the model is a list of strongly-typed FavouriteName objects. Intellisense doesn’t work in the beta version, so we are unable to show you the benefits of using a strongly-typed view. You can use the following code to render the favourite given names:

@model IEnumerable<MvcApplication5.Models.FavouriteGivenName>
@{
    View.Title = "StronglyTypedView";
    Layout = "~/Views/Shared/_LayoutPage.cshtml";
}

<h2>Strongly Typed View</h2>
<p>
      @foreach(var givenName in Model) {
            @givenName.Name <br />
      }
</p>

The @model keyword is easy to miss when you’re using the beta version of ASP.NET MVC 3 Beta, but it’s something you’ll learn once and never forget it’s there.

Brief Description

ASP.NET MVC 3 Preview 1 provides a new Model-View-Controller (MVC) framework on top of the existing ASP.NET 4 runtime


Overview

ASP.NET MVC 3 is a framework for developing highly testable and maintainable Web applications by leveraging the Model-View-Controller (MVC) pattern. The framework encourages developers to maintain a clear separation of concerns among the responsibilities of the application – the UI logic using the view, user-input handling using the controller, and the domain logic using the model. ASP.NET MVC applications are easily testable using techniques such as test-driven development (TDD).

The installation package includes templates and tools for Visual Studio 2010 to increase productivity when writing ASP.NET MVC applications. For example, the Add View dialog box takes advantage of customizable code generation (T4) templates to generate a view based on a model object. The default project template allows the developer to automatically hook up a unit-test project that is associated with the ASP.NET MVC application.
Because the ASP.NET MVC framework is built on ASP.NET 4, developers can take advantage of existing ASP.NET features like authentication and authorization, profile settings, localization, and so on


System Requirements

Supported Operating Systems:Windows 7;Windows Server 2003;Windows Server 2008;Windows Vista

.NET 4, ASP.NET 4, Visual Studio 2010 or Visual Web Developer 2010 are required to use certain parts of this feature


Instructions

For more information about installing the release, see the ASP.NET MVC 3 Preview 1 Release Notes


Top Reasons to trust your ASP.NET MVC 3 website to ASPHostCentral.com

What we think makes ASPHostCentral.com so compelling is how deeply integrated all the pieces are. We integrate and centralize everything--from the systems to the control panel software to the process of buying a domain name. For us, that means we can innovate literally everywhere. We've put the guys who develop the software and the admins who watch over the server right next to the 24-hour Fanatical Support team, so we all learn from each other:

- 24/7-based Support - We never fall asleep and we run a service that is operating 24/7 a year. Even everyone is on holiday during Easter or Christmas/New Year, we are always behind our desk serving our customers
- Excellent Uptime Rate - Our key strength in delivering the service to you is to maintain our server uptime rate. We never ever happy to see your site goes down and we truly understand that it will hurt your onlines business. If your service is down, it will certainly become our pain and we will certainly look for the right pill to kill the pain ASAP
- High Performance and Reliable Server - We never ever overload our server with tons of clients. We always load balance our server to make sure we can deliver an excellent service, coupling with the high performance and reliable server
- Experts in ASP.NET MVC 3 Hosting - Given the scale of our environment, we have recruited and developed some of the best talent in the hosting technology that you are using. Our team is strong because of the experience and talents of the individuals who make up ASPHostCentral
- Daily Backup Service - We realise that your website is very important to your business and hence, we never ever forget to create a daily backup. Your database and website are backup every night into a permanent remote tape drive to ensure that they are always safe and secure. The backup is always ready and available anytime you need it
- Easy Site Administration - With our powerful control panel, you can always administer most of your site features easily without even needing to contact for our Support Team. Additionally, you can also install more than 100 FREE applications directly via our Control Panel in 1 minute!

Happy hosting!

ASP.NET MVC is a free, fully supported, Microsoft product that enables developers to easily build great web applications. It provides total control over your HTML and URLs, enables rich AJAX integration, and facilitates test driven development.


Here is a list of various ASP.NET MVC Sample Applications demonstrating the new ASP.NET MVC Framework from Microsoft. If you like to have any of these applications hosted on a server, you can consider ASPHostCentral.com as your ASP.NET MVC hosting provider. With a package starting from only $4.99/month, you can have the latest ASP.NET MVC 2 RC framework running on our server.


CarTrackr

CarTrackr is a sample application for the ASP.NET MVC framework using the repository pattern and dependency injection using the Unity application block. It was written for various demos in presentations done by Maarten Balliauw. CarTrackr is an online software application designed to help you understand and track your fuel usage and kilometers driven. You will have a record on when you filled up on fuel, how many kilometers you got in a given tank, how much you spent and how much liters of fuel you are using per 100 kilometer. CarTrackr will enable you to improve your fuel economy and save money as well as conserve fuel. Fuel economy and conservation is becoming an important way to control your finances with the current high price

http://cartrackr.codeplex.com/


Codecampserver

This is the source code repository for CodeCampServer, a free, open source Code Camp management web application.

http://code.google.com/p/codecampserver/


Contact Manager

In this series of tutorials, Stephen Walther demonstartes how to use the ASP.NET MVC framework to build an entire Contact Manager application using unit tests, test-driven development, Ajax, and software design principles and patterns

http://www.asp.net/mvc/


FlickrXplorer

The project is an open source initiative to present users a fast photo explorer and search tool to browse millions of photos in flickr. The app is made with a bit of jQuery blend using Asp.net MVC and custom LINQ. The project also embodies a cloud computing scenario where the actual datastore lies millions of miles away invoked though simple API. The Application gives a nice starting point for Asp.net MVC, it also shows a strong integration of jQuery with Asp.net MVC as a client framework. It uses Athena (http://www.codeplex.com/LinqFlickr) LINQ to flickr API for fetching in and out data which is made on a custom LINQ provider toolkit made best for creating LINQ to Cloud APIs (http://www.codeplex.com/LinqExtender).

http://flickrxplorer.codeplex.com/


Kigg

KiGG is a Web 2.0 style social news web application developed in Microsoft supported technologies. The project uses ASP.NET MVC, Linq To SQL, MS Patterns & Practices Enterprise Library and Unity, jQuery, xUnit.net, Moq, HtmlAgilityPack, DotNetOpenId, and other 3rd party libraries

http://www.codeplex.com/Kigg


MVC StoreFront

I'm creating an ongoing series of webcasts and blog posts, documenting the building of an eCommerce storefront using ASP.NET MVC

http://blog.wekeroad.com/mvc-storefront/


Nerddinner

NerdDinner.com is an event management site so computer folks can meet and talk technology over a meal. It uses ASP.NET MVC along with jQuery, ASP.NET Ajax, Virtual Earth Javascript controls, and LINQ to SQL. It’s also a real site running at NerdDinner.com that you can use to schedule geek meet ups and nerd dinners in your neighborhood!

http://nerddinner.codeplex.com/


Oxite

Oxite is an open source, web standards compliant, blog engine built on ASP.NET MVC and LINQ To SQL. Oxite supports all the features we consider essential to a blog engine, including the MetaWebLog API (to allow you to use LiveWriter or similar tools to add/edit your posts), trackbacks, pingbacks, Sitemaps (for search engines), RSS and ATOM feeds (at the site, blog, tag and post level ... plus feeds of all new comments... great for the site owner), tags, integrated search, web based admin features (including editing posts, your site settings, etc.), email subscriptions for new comments, basic support to publish 'pages' (non-blog content) and more.

http://www.codeplex.com/oxite