Managing configuration settings for different environments with config transformations

When you create a new web application in Visual Studio 2010, you will by default get a configuration file like this:

Web.config transformations

The web.config transformations allow you to adapt your configuration settings for different builds or environments. We have all worked with development, test and production environments where our settings differ from each other like:

  • Database connection strings
  • Endpoints
  • Credentials
  • Domains
  • Application settings
  • Debug mode
  • Tracing
  • Folders or shares
  • ….

When working with different environments, you are bound to be working with different configuration settings. Web transformations allows us to transform our configuration file to the correct configuration file for the environment we want to publish to. By default we get a Debug and Release transformation file. We want to add a tranformation file for developent, test and production environment.

1. How to use web.config transformations to manage your different configurations

For demo purposes we will take a simple web.config file which looks like the following:

Using web.config transformations to manage configuration for different environments

This is the web.config file which is containing our development settings. We will start by changing our configurations by the Configuration Manager:

Continue reading


Serializing your javascript objects or collections to valid json to submit with an ajax-enabled WCF service

Recently, one of the things I found myself struggling a bit with, was submitting my javascript object collection to an ajax-enabled WCF service which was expecting a object or object collection of a certain type. At first I kept getting format errors because my self created JSON object collection was not formatted correctly and thus the object collection could not be parsed correctly by our ajax WCF service.

Suppose we have a very simple data contract:

Serializing javascript object collection to valid json for ajax WCF service

We have an AJAX-enabled WCF service, that has a method that accepts an ienumerable of our data contract:

Serializing javascript object collection to JSON for AJAX enabled WCF service

We can build our object in javascript with the available properties and serialize the array with JSON.stringify:

Serializing javascript objects to JSON with JSON.Stringify

The result of JSON.stringify on the javascript object array will be a JSON parsed collection of employee:


The other solution is to write your objects in the JSON format immediately, but that is not any fun thing to do. When you are starting to build complex collection with multiple object levels, writing the json format manually is almost impossible. JSON.stringify just does the work for you!


Building and consuming REST services with ASP.NET Web API using MediaTypeFormatter and OData support

The ASP.NET Web API has been released with the ASP.NET MVC4 beta release, which was released 2 days ago (14/02/2012).

You can download the ASP.NET MVC4 beta release, that includes the Web API, here:

Quoted directly from microsoft website:

ASP.NET MVC 4 also includes ASP.NET Web API, a framework for building and consuming HTTP services that can reach a broad range of clients including browsers, phones, and tablets. ASP.NET Web API is great for building services that follow the REST architectural style, plus it supports RPC patterns.

If you do not know what REST stands for and why it could be of any use, you can watch this 1h18m08s video on channel9 by Aaron Skonnard:

Considering how popular REST is these days, it might be interesting to cover the new Web API in this post. Originally we saw REST services coming up through the WCF pipeline, like the WCF Data Services or using a common WCF service with the WebHttpBinding, which works on HTTP verbs like GET, POST, PUT and DELETE. However WCF was created as a messaging platform, on which we are working with SOAP messages. The entire WCF pipeline is also optimized for messaging. REST services do work a bit differently, nor do they use any SOAP. Apparently Microsoft came to the conclusion that the integration of REST was not ideal with the WCF messaging pipeline so they moved the possibility to create REST services within the ASP.NET Platform.

Continue reading