ThreadAbortException

April 2012 Entries

JsonValueProviderFactory in MVC 2

Today we were rebuilding an old project which used MVC 2.  There were a bunch of build errors, which I quickly figured was because of the reference to Microsoft.Web.MVC assembly which was a part of the Futures Preview for MVC 2 before MVC 3 came.

I removed the reference and secondly, I installed MVC 3 on the machine.  After that I removed all references to MVC 2 assemblies and added reference to the System.Web.Mvc dll version present in C:\Program Files(x86)\Microsoft ASP.NET\ASP.NET MVC 3\Assemblies.

With that, some of the errors went off.  But upon further building the project, I ran into quite a few issues with respect to Razor Views and existing MVC 2 codebase.

My colleague, as paranoid as always wanted to revert back to MVC 2 given that, there would be more work in changing all of them to suit MVC 3 assemblies and it wasn’t required at this time for a project which was working fine.  Typical customer style.

Then, I went ahead and removed the reference to MVC 3 and added back the MVC 2 assembly.

Bang came back the error on JsonValueProviderFactory references in Global.asax.  After scratching around for sometime, I figured that this assembly is now part of the System.Web.Mvc in MVC 3 whereas if we have to use it in MVC 2, we need to explicitly download and add the MVC 2 Futures Preview available at http://aspnet.codeplex.com/releases/view/41742 

Since the code was ported from another machine, this wasn’t copied and just MVC and required assemblies were installed.

I went ahead and installed the MVC 2 features which had the DLL Microsoft.Web.Mvc and after adding a reference to that DLL in the project and then putting up a using Microsoft.Web.Mvc, the error on line JsonValueProviderFactory vanished.

Please note, this is only required if you stick to use MVC 2 and with MVC 3 and above, this is not required.

Also, the MVC 2 futures was an experimental release, so I would assume it wouldn’t be supported and one has to use at one’s own risk.

Cheers !!!

Single Page Application and why is it becoming more and more popular

One of the key trends becoming more and more popular is the Single Page Application Framework and building applications that behave as native applications running on the machine.

SPA’s have been tried and tested for a while now and with libraries like Knockout.js, Backbone.js becoming more and more capable, it becomes feasible to create SPA’s.

What is an SPA?

I can describe in length but falling in line with DRY principle, here is the Wiki Link http://en.wikipedia.org/wiki/Single-page_application

But in short, it is a framework that builds highly responsive web applications that don’t infuse post backs and page reload. 

I can almost hear you say.

“Wait!! Isn’t that what AJAX and XMLHttpRequest promised?”

“Can’t I do it with Iframe?”

Hence this post, “Why SPA” now

Traditional web developers have tried using a variety of means to do this Single Page Application using Iframes, XMLHttpRequest, AJAX, jQuery and a variety of libraries.  There are caveats to each of these approaches.

First major issue with Iframes is the ability to communicate between the parent and the iframe.  80% of questions about Iframe in various forums (including my most popular blogpost on iframe) are about communication between the page in iframe and the parent.

The next with respect to asynchronous call backs is that, the URL doesn’t get updated and this causes 2 issues

1. There aren’t much URLs and hence the website isn’t search engine friendly

2. Users press the “Back” button and get an unexpected behaviour since the browser history is not updated and hence takes them to different locations instead of the previous stage.

How Single Page Application solves these issues?

Single Page Applications use a parameterized URL which defines various operations that you do.  For example, it may append an action to the base URL as below

http://localhost:2015/Task/?editItem=added5

Secondly, SPAs use history.js library (native.history.js) for maintaining the state of the page, so even though all the operations happen quickly and on the client side, the browser’s back button behaves normally and the page state is saved.

In addition to solving the above problems, SPA’s use a combination of template binding scripts, Data Model Scripts, Services and Data Templates making it all the more richer in functionality, to build.

Finally, SPAs integrate well with the new HTML5 features such as LocalStorage and Application Cache for building Offline Web Applications and make it easy to build apps that behave the same when not connected.

What does Microsoft have for developers?

In MVC4 Beta, there is Single Page Application Template that allows you to build SPAs with minimal effort.  The default template comes with all the required libraries wired up and a sample ToDoItem.cs file which is the model for data.  Upon building the solution and creating a TasksController which is based on the ToDoItem Model, one can navigate to the base URL + Tasks to experience creating /editing Tasks all of it in a Single Page Experience, both quick and elegant.

And since this post has been all talk and no technical tip, here below is one.

The Default SPA Template that comes up when you create a “File – New – ASP.NET MVC 4 Web Application – Single Page Application” Project which was released along with VS11 Beta is a bit out dated now.

Once the SPA Template Project is created, we need to run the NuGet command line utility (Tools – Package Manager Console) and type Install-Package SinglePageApplication.CSharp

This gives a much improved SPA Template to work with as outlined by Steve Sanderon himself, in his blog post.

Cheers !!!