When you create a new web application in Visual Studio 2010, you will by default get a configuration file like this:
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
- Application settings
- Debug mode
- 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:
This is the web.config file which is containing our development settings. We will start by changing our configurations by the Configuration Manager:
Suppose we have a very simple data contract:
We have an AJAX-enabled WCF service, that has a method that accepts an ienumerable of our data contract:
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!
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: http://channel9.msdn.com/Blogs/matthijs/Why-REST-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.