All Posts Tagged ‘spa


DeliveryTracker with ASP.NET MVC 4 RC


Well, this blog post is about how to make SPA work with RC. The discussion started at

My plan is to share experiences with the SPA (which is a little bit paused now by the team), so don’t expect a complete guide about it now, this will be a series of posts as we move forward and resolve new issues.

As you may already know, SPA is removed from the ASP.NET MVC 4 stack and continued as a separate project. Another problem is the pause on it, so it’s a very unstable area. New problems come day-to-day and old ones get resolved. For example when I first wrote to the codeplex discussion thread about that we resolved the incompatibility between SPA and RC we had some server side problems that disappeared with the current nightly build, but we don’t have OData filters now :).

In this article I will try to make the DeliveryTracker work with the latest MVC builds. If you need the OData filters with SPA right now, you should go with an older changeset (as we do) or another OData lib. For more information check out this thread:

One more thing before we dive into is that we don’t really use EntityFramework and we didn’t explore everything about this stack. Ahh, and this is my first blog post btw. 🙂

Ok, first of all, you will need the DeliveryTracker sources:

To get the latest MVC nightly builds follow the instructions here:

You will also need the webstack sources, because the SPA related packages don’t have nuget builds:

If you got all the stuff then open up the DeliveryTracker solution. You will see that it has the beta MVC packages delivered with it. Update the following ones from the nightly source:

  • Web Api Client
  • Web Api Core
  • Web Api Web Host

If you try to run the solution now you will get an application error. This is because the Web Api changed since the beta SPA.

Let’s do some changes!

We need four components for our SPA solution:

  • System.Web.Http.Data
  • System.Web.Http.Data.EntityFramework
  • System.Web.Http.Data.Helpers
  • upshot.js

You can find these packages in the aspnetwebstack source, but now they belong to the Microsoft.* namespace (probably because they continue SPA as a single project).

We will create 3 new projects inside our DT solution and clone the following 3 from the latest:

  • Microsoft.Web.Http.Data
  • Microsoft.Web.Http.Data.EntityFramework
  • Microsoft.Web.Http.Data.Helpers

This is because we probably have to make some changes to make it work or to keep our solution working at the next nightly update (not absolutely necessary now, but it’s safer).

Open up the Runtime.sln (which comes with the latest sources), and check out the Microsoft.Web.Http.Data project. There you will find some linked files in the Common folder so don’t forget to copy those too.

Include the files and do the same with the Microsoft.Web.Http.Data.Helpers and System.Web.Http.Data.EntityFramework.

After you have the sources in the DT you probably have to add nuget packages to the new projects too, such as

  • Web Api Client
  • Web Api Core
  • Web Api Web Host

And some reference from the .NET:

  • System.Runtime.Serialization
  • System.ComponentModel.DataAnnotations

If I missed something here then you will need to figure out it yourself (or ask me in a comment), but I hope this list is complete.

The next few steps are temporary solutions, but this whole thing we do here is temporary anyway. So when you try to build it you will get a lots of internal usage error, but who needs internal protection while our goal is to hack around the problems? So change them to public. Do it everywhere the compiler complains about it.

Another problem you will face here is the resource accessing in Errors.cs, you can figure out what’s going on here if you want but I don’t care about the concrete error resource now (it’s really a temporary solution), just change it like in the attached picture.

I don’t really remember, but there is a

using System.ComponentModel.DataAnnotations.Schema;

directive somewhere in the Microsoft.Web.Http.Data that we don’t need and the compiler can’t find it. If you have ReSharper then it’s more easy.

You should have a successful build now (and I hope you have!).

Ok, now we have a DT with the latest MVC and 3 SPA related projects around it. You have to remove the old references from DT and add our new projects:

  • System.Web.Http.Data
  • System.Web.Http.Data.EntityFramework
  • System.Web.Http.Data.Helpers
  • System.Web.Http.Data.Helpers2

The problem now is that the new code has a different namespace. So change them! (System.* -> Microsoft.*)

Delete EntityFramework and install a new one from nuget because we use a newer one in Microsoft.Web.Http.Data.Helpers and we don’t want version missmatch errors.

Also we have to update our namespaces in our web.config files (in the normal and under the Views too).

<add assembly=”System.Web.Http.Data.Helpers, Version=, Culture=neutral, PublicKeyToken=31bf3856ad364e35″ />
<add assembly=”Microsoft.Web.Http.Data.Helpers” />

and under the Views
<add namespace=”System.Web.Http.Data.Helpers” />
<add namespace=”Microsoft.Web.Http.Data.Helpers” />

Ok, the code is ready and it should run now (we will have client side errors).

The new server side code generates a different result and our upshot.js is from the beta package. We need to update and fix that too.

Check out the SPA project in the Runtime solution. Upshot made up from different components, so you have to build (combine) the files.

When I made this step for us, the upshot.js had some incompatibility with the current server code, but we will check out what’s the situation now.
I made a little cmd tool to combine the files, you can find the source code here. Copy the exe into the SPA folder and run it. You should have an upshot.js now.

Overwrite the original with it and change the path in the _SpaScripts.cshtml partial.

Well, upshot still has incompatibility problems, so lets fix them. The main difference between the old and the new json pushed by the server is the structure, you can inspect it.

The other is the type handling. I’m not going to write about them one-by-one, you can download the fixed upshot.js and the script file which contains the actual fix functions here.
In the upshot.js I have marked the fixed parts with a comment: //FIX, so you can check out them.
You have to include the SPAHacks.js before upshot to make it work. Refresh the page and voila.

This is it. I hope everything worked out, but if not, you can always ask in comments.

As you can see it’s not a fail proof way to build applications, so I suggest to wait until a stable release comes out. If you don’t want to wait (like me) you can play with it, and I’m going to write more posts when we have more problems.