Post Format

DeliveryTracker with ASP.NET MVC 4 RC

14 comments

Well, this blog post is about how to make SPA work with RC. The discussion started at http://aspnetwebstack.codeplex.com/discussions/358133

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: http://aspnetwebstack.codeplex.com/discussions/359229

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: https://github.com/SteveSanderson/DeliveryTracker

To get the latest MVC nightly builds follow the instructions here: http://blogs.msdn.com/b/henrikn/archive/2012/06/01/using-nightly-asp-net-web-stack-nuget-packages-with-vs-2012-rc.aspx

You will also need the asp.net webstack sources, because the SPA related packages don’t have nuget builds: http://blogs.msdn.com/b/henrikn/archive/2012/04/09/getting-started-with-asp-net-web-stack-source-on-codeplex.aspx

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:

  • ASP.NET MVC 4
  • 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

  • ASP.NET MVC 4
  • 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).

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

and under the Views
<add namespace=”System.Web.Http.Data.Helpers” />
to
<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.

About these ads

14 Comments Join the Conversation

  1. This is killing me: Could not load type ‘System.Web.Http.Controllers.IControllerConfiguration’ from assembly ‘System.Web.Http’; Microsoft.Web.Http.Data can not be compiled because two types are missing in the DataControllerConfigurationAttribute.cs file: “IControllerConfiguration” and “HttpControllerSettings”, does this mean i have to clone the System.Web.Http project(from the aspnetwebstack source) into my solution too?

    Reply

  2. Hi Dean,

    No, you don’t have to clone that project, because web api is in active development.
    The problem here is the version of the System.Web.Http assembly. Did you change to the nightly build package? What is the version and the path of the System.Web.Http reference in the Microsoft.Web.Http.Data project?

    Reply

  3. @Peter, have you tried to do this on the BigShelf Demo Project? More incompatible problems with the old js entities and viewModels, I may have to go back to mvc4 beta, sadly…well, still looking forward to see your new posts :)

    Reply

    • Hi Dean,
      Yes, we are using more features than in this post (e.g. OData). DeliveryTracker is the easiest one to make compatible. Definitely, my plan is to write a BigShelf howto as that is more complex.

      Reply

  4. What did you do about the fact the assembly isn’t signed – e.g. I’m getting an error which says:

    Could not load file or assembly ‘Microsoft.Web.Http.Data’ or one of its dependencies. Strong name signature could not be verified. The assembly may have been tampered with, or it was delay signed but not fully signed with the correct private key. (Exception from HRESULT: 0×80131045)

    Reply

    • Are you created a new project for Microsoft.Web.Http.Data in the DeliveryTracker solution and copied the files there or you just included the existing project? By default the latest sources come with delay sign so if you build from that source you get delay signed assemblies (the nightly build has full strong name signature). You should create the two project in DeliveryTracker or turn off signing completely (project properties/signing). Be aware that the AspNetWebStack source delay signing also has a setting flag in the tools/WebStack.settings.targets file so you should turn that off too. Another approach is to approve those two assembly to run without strong name (see strong name skipping for sn.exe), but I suggest to create the two project as I wrote, because you may have to fix things later in that two projects too.

      Reply

  5. I have a SPA challenge, I want one stored proc and one controller which accepts sql statement and its given name (to piggyback what was the sql about). The controller passes it to the stored procedure which validates the sql for any attacks (this particular stored procedure will be running from a read-only account, so I am not so much worried about attacks to be precise) and will return a result set (of table type). The controller will return will pass it on to upshot as is. As we already know the given name of it, it can find the javascript view model for it to bind against and display to the user. I think this is the best way of creating a customizing a data driven dashboard, but I have no idea where to start from (and how upshot will identify when there is no C# class to match against). Your advice is greatly appreciated.

    Reply

    • I don’t think upshot is the right choice in your case. You don’t really need entity tracking and crud at all (which is a great part of upshot). You might feel more comfortable with a simple MVC4 Web Api solution. You can use knockout with Web Api too..

      Reply

Leave a Reply

Required fields are marked *.

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s