Bundling and Minification in ASP.NET MVC

Richness of Web Content has been growing at a phenomenal pace and thanks to Modern browsers supporting HTML5 and CSS3, with a little work, a Web Application can be made almost as rich as Native applications. Yes, they are still a little behind but Web today is unrecognizable from web 5 years ago.

This rich-ness of behavior on the web, is all thanks to the power of JavaScript frameworks, libraries and plugins, whereas the rich user experience comes from effective use of graphics and CSS3.

However all this has a cost. If we look at a plain vanilla ASP.NET Web Template in Visual Studio, it has a total of eight (8) JavaScript files and sixteen (16) css files. Now most of these are loaded in the _Layout page. Some are loaded as required in Forms Pages. But how does the loading of these many artifacts affect the performance of your web site? Let’s find out.

Uploading Multiple Files through an ASP.NET Web API Service

I had written a post on DotNetCurry on how to upload multiple-files to an Azure Blob through an ASP.NET MVC Web Application. Today we’ll see how we can do the same but store it in a file system instead and use a Web API controller instead, so that the upload service can be hosted anywhere we want. For brevity, we’ll build our Web API sample to use ASP.NET/IIS host.

The API Controller

Step 1: We start off with a Basic Web Application Template and add an empty API Controller to it.

Step 2: Next we add an Upload method to which the Files will be posted. The complete method is as follows:

Using MvcScaffolding Packages to Generate Repositories for your LoB Applications

ASP.NET MVC’s tooling support goes a long way in making it a LOB Application friendly platform. However the default Controller scaffold contains direct references to the DBContext. This is a little smelly when it comes to separation of concerns and can often lead to ending up with ‘fat-controllers’. Instead, if our Scaffolder could generate a Repository Interface and its corresponding implementation, our LoB apps would not only achieve better ‘separation of concerns’ but also becomes more testable. The MvcScaffolder extension that comes as Nuget Package enables us to do precisely this type of scaffolding. Let’s see how we can use it in a simple Contact app.

Getting Started – Installing MvcScaffolder

Step 1: We start off by creating a new MVC 4 Application in Visual Studio. We use the Basic Application template for now.

Implementing Pagination in ASP.NET Web API using OData operators

ASP.NET Web API is a framework that makes it easy to build HTTP services for various types of clients from Microsoft to Non-Microsoft technologies. The new programming model of developing over HTTP is made simple and flexible by using WebAPI. We can design services which can be accessible from a broad range of clients, including browsers and mobile devices.

One of the most frequent requirements while retrieving data using WEB API is that how to implement pagination so that only a subset of data is fetched from the server. To implement this, OData queries with WEB API can be used. You can get more information about the OData Queries from here.

Let us build a simple application that can filter multipage data using OData queries directly.

The Web API Demo

Step 1: Open VS 2012 and create a new Empty MVC application. Name it as ‘MVC40_WEBAPI_Pagination’. Since we will be using jQuery and Knockout.js framework, on this project right click and using ‘Manage NuGet Package’, get the latest jQuery and Knockout script files.

Adopting ASP.NET MVC enhancements in an Existing Web Forms Project

This article is from our ASP.NET MVC 101 Tutorial Series

Whenever we are starting with a Greenfield project, that is a new project from ground up, we prefer using the latest in the technology stack to the point where the team is comfortable with. However, Greenfield projects are pretty rare; enhancement and feature addition projects, often referred to as brown-field projects, are the way forward for existing applications in an Enterprise. In these projects, we are often saddled with predetermined technologies or frameworks and shoe horning the latest and greatest could mean un-necessary delays and instability. After all ‘don’t fix what’s not broken’ right?

Given this scenario, it’s common to have well established ASP.NET 2.0 Web Forms projects that need enhancements. If the enhancements are independent enough, as in creation of new Screens with new functionality, that is no way going to be ‘embedded’ in existing functionality. We can take a clean break and develop the new functionality in ASP.NET MVC by mixing and matching Web Forms with MVC.

Today we will take a look at the caveats, gotchas and the GUIDs we need to take care to make this possible.

Tracing in ASP.NET Web API

Tracing plays an important part in keeping track of how things are flowing through in your Application Services. Configuring tracing to collate system output is invaluable in gathering correct information about what the service is actually doing other than throwing a HTTP 5xx or HTTP 4xx error.

If you want to implement a TraceWriter of your own, you can implement the ITraceWriter and register it as the required or you could use the Microsoft.AspNet.WebApi.Tracing package from Nuget and simply turn on Tracing.

Before we look into tracing let’s take a sneak peek behind the ‘interesting’ implementation of Tracing in Web API.

Testing CRUD Operations in ASP.NET Web API using Fiddler

HTTP Services can be used by a broad range of clients including browsers and mobile devices. By using REST [Representational State Transfer] we can build loosely coupled services.

When we think about exposing data on the web, we always talk about four common operations which we use in our day-to-day life –

1. Create
2. Retrieve/Read
3. Update
4. Delete


We call these operations as CRUD operations. HTTP provides 4 basic verbs which we can map to our CRUD operations as described below –

1. POST – CREATE
2. GET – RETRIVE
3. PUT – UPDATE
4. DELETE – DELETE

HTTP Cookies and ASP.NET Web API

HTTP Cookies are bits of information sent by an HTTP Server in an HTTP Response. So when a browser is said to ‘drop a cookie’, it basically implies that the ‘HTTP Client’ (browser in this case) received a Cookie from the server and has persisted it on the client. The ‘HTTP Client’ then returns this cookie to the server via the Cookie Header in subsequent requests.

To dig in just a little bit further, scope of an HTTP Cookie is controlled by attributes set in the cookie header.

- Expires: A Date/Time value indicating when the cookie should expire. The client deletes the cookie once it expires.

- Max-Age: A numeric value representing a timespan span indicating life of the cookie. Like in case of Expires, the cookie is deleted once it reaches it maximum age. Between Expires and Max-Age, Age takes precedence. If neither is set, client deletes the cookie once the ‘session’ expires

- Domain: Specifies the domain which receives the cookie. If not specified, domain is the origin server.

- Path: Limits the cookie to the specified path within the domain. If not specified, the URI’s path is used.