IIS 7.5: Could not load type 'System.ServiceModel.Activation.HttpModule'

On an IIS 7.5 I wanted to deploy a .NET 3.0 WCF application. As no handler was registered for *.svc extension on the CLR 2.0, I ran the servicemodelreg.exe tool available in at C:\Windows\Microsoft.NET\Framework\v3.0\Windows Communication Foundation.

However this broke all my existing .NET 4.0 WCF services. The .NET 4.0 svc mapping was replaced by the .NET 2.0 version. As a consequence, every service call resulted in the following error message:

Could not load type 'System.ServiceModel.Activation.HttpModule' from assembly 'System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'.

This error occured because I installed the 3.0 version of the WCF Http Activation module is installed after installing IIS and .NET Framework 4.

How did I fix this? 

Running the servicemodelreg.exe for .NET 4.0(available at C:\Windows\Microsoft.NET\Framework\v4.0.30319) had no effect.

In the end I found that I had to use the ASP.NET IIS Registration Tool (Aspnet_regiis.exe) to register the correct version of ASP.NET.

Don’t forget to add the –iru parameters when running aspnet_regiis.exe.

ASP.NET MVC 3: ViewContext.FormContext

ASP.NET MVC 3 introduced the concept of unobtrusive client validation. Based on data annotations on top of your model,  the HTML helpers render markup with validation info using the HTML5 data attribute:

<input data-val="true" 
data-val-required="The ProductName field is required."
id="ProductName" name="ProductName" type="text" />

These data attributes are picked up by the jquery.validate.unobtrusive library that constructs the correct validation rules for jquery.validate.

ViewContext.FormContext

In our project, we load some parts of the user interface dynamically based on some user actions. We noticed that the MVC framework didn’t render the data attributes in that case.


What’s the reason? We found out attributes with validation rules are rendered only if the ViewContext.FormContext property is initialized. It could be done with Html.BeginForm() method called in the beginning but, as in our case there was already a form on the page, so we set the FormContext manually:

if (ViewContext != null && ViewContext.FormContext == null)
{
 var dummyFormContext = new FormContext();
 ViewContext.FormContext = dummyFormContext;
}

ASP.NET MVC 3: A Potentially Dangerous Request.Form Value was Detected From The Client

Last week, our users reported a bug that they got the following error back when  submitting some data inside the ASP.NET MVC application we are building:

“A potentially dangerous Request.Form value was detected from the client.”

 

This is caused by the ASP.NET request validation. Request validation is actually a good thing since it keeps people from injecting script tags in our application for Cross-Site Scripting ( XSS ) attacks. OK that’s fine, I understand this from a security perspective. But what if the user should be able to enter some special characters in some fields?

AllowHtmlAttribute

Let’s introduce the AllowHtmlAttribute, a property attribute that we can include on model properties to disable request validation on a property by property basis. Now we can turn off request validation just on the properties we want by adding the [AllowHtml] Attribute to it:

public class Order
{
	public string Description{get;set;}
	
	[DataType(DataType.MultilineText)]
	[AllowHtml]
	public string Remarks {get;set;}
}

Automapper Array mapping issue

For a project we are using Automapper to map our domain model to our WCF DataContracts.

Last week a bug was logged that a DTO with an array property was set to a zero-length array, although the source instance has the property set to null. We expected that the destination value would also be null. As all our DataContracts are validated against our XSD schemas, an error was thrown.

On the GitHub Automapper site we found that this was already reported as an issue. As a result a new configuration option was added.

If you didn’t download the latest version from the GitHub site but are using an official release, you can get around the issue by using the following code:

Mapper.CreateMap<Order, OrderDTO>()
    .ForMember(o => o.OrderLines, opt => opt.ResolveUsing(o => o.OrderLines== null ? null: o.OrderLines));

Microsoft adds Mocking/Isolation support to Visual Studio 11

A lot has changed on the testing front inside Visual Studio 11.(If you want to know a good overview of all the changes: http://www.peterprovost.org/blog/post/Whats-New-in-Visual-Studio-11-Beta-Unit-Testing.aspx). One interesting feature I noticed in this long list of changes is the introduction of their own isolation framework:

The Visual Studio Fakes Framework

“Microsoft Fakes is an isolation framework for creating delegate-based test stubs and shims in .NET Framework applications. The Fakes framework can be used to shim any .NET method, including non-virtual and static methods in sealed types.”

Wow! As it also will support to fake both non-virtual and static methods, I can finally isolate some of the harder to (unit)test parts of the .NET ecosystem.

The Fakes framework helps developers create, maintain, and inject dummy implementations in their unit tests. It provides two ways to do this:

• Stub types Stub types make it easy to test code that consumes interfaces or non-sealed classes with overridable methods. A stub is realized by a distinct type which is generated by the Fakes Framework. As a result, all stubs are strongly typed. 
• Shim types Shim types allow detouring of hard-coded dependencies on static or non-overridable methods. A shim of type T can provide an alternative implementation for each non-abstract member of T. The Fakes Framework will redirect method calls to members of T to the alternative shim implementation.

Creating Fakes is as easy as right-clicking on one of your project references and choosing Add Fakes Assembly.

Read more about the Visual Studio Fakes Framework in the MSDN Documentation.

• Using stubs to isolate calls to virtual functions in unit test methods
• Using shims to isolate calls to non-virtual functions in unit test methods
• Code generation, compilation, and naming conventions in Microsoft Fakes

Remark: I didn’t add any sample code, as the syntax could still change.

Team Foundation Server Licensing changes

Microsoft introduced some interesting changes last week regarding the TFS licensing requirements.

What’s changed?

• Team Explorer Everywhere: You no longer need to purchase Team Explorer Everywhere separately. Before today, Team Explorer Everywhere users had to purchase both a Client Access License (CAL) and the Team Explorer Everywhere software, whereas Visual Studio Team Explorer users only had to purchase a CAL – the Visual Studio Team Explorer software has always been a free download (TE 2008, TE 2010, TE 11 Beta) for users who had a license to access a TFS server. Now the story is the same for Team Explorer Everywhere (TEE 2010 with SP1, TEE 11 Beta).
• Team Foundation Server Reporting – Microsoft removed the TFS CAL requirement  for viewing reports in TFS. This addresses a long standing concern that it was not reasonable to require a CAL for the occasional stakeholder who wanted to check a report to see progress or issues.
• Using TFS from within Microsoft System Center Operations Manager – With the upcoming release of System Center 2012, you will be able to connect your operations team to your development team, allowing them to better collaborate on production issues. Operations Manager 2012 includes the ability to escalate tickets and all the associated diagnostic data to development by connecting it to Team Foundation Server. The licensing is updated to enable your Operations Manager users to take advantage of this integration without also needing a TFS CAL.

More information and all the details here: http://blogs.msdn.com/b/bharry/archive/2012/03/08/even-better-access-to-team-foundation-server.aspx

ASP.NET MVC 3: Configuring unobtrusive validation

ASP.NET MVC 3 ofeers client side validation through the unobtrusive javascript and jQuery validation plugins. Most of the time the default behavior is fine, but what if you want to tweak the validation configuration?

Only validate the form fields when the form is submitted:

$(function() {
 var validationSettings = $.data($('#formToValidateId').get(0), 'validator').settings;
 validationSettings.onkeyup = false;
 validationSettings.onfocusout = false;
});

As you can see, it’s possible to change some settings through the  validator settings object. By setting  the onkeyup and onfocusout properties to false, the validation on blur and key up will be disabled.

Disable the validation on input fields with class ignore.

$(function() {
 var validationSettings = $.data($('#formToValidateId').get(0), 'validator').settings;
 validationSettings.ignore = '.ignore';
});

Setting the ignore property of validator settings object to .ignore will tell the jQuery validation plugin to ignore all input elements with class ignore during validation. 


Of course there are a lot more options you can configure. For a complete list of jQuery validation options have a look here.