Saturday 7 April 2012

ASP.NET Web API beta Source code: Survival Guide

[Level T2]
NOTE on 01/06/2012: ASP.NET Web API RC was released last night (31/05/2012). This means for a while at least, you do not have to build the nightly releases. You can download it from here.

Just a quick note that as you probably know, ASP.NET Web API beta (along with ASP.NET MVC 4 beta) is out. Scott Guthrie announced the release in his blog on 27th of March and it has been released under Apache 2.0 license.

You may download the source code from here via git or web . This is a really good news for all who wanted to have a deep dive into the implementation and extensibility points of the framework - including me. The media was also surprised on the release as it shows perhaps another shift in Microsoft towards community-oriented software development - but I will leave this subject for another occasion.

It is interesting that the source code comes with full unit testing coverage, yet it does not use MS Test framework available in Visual Studio instead it uses xUnit, a framework among whose contributors is Brad Wilson. This gives us a bit more insight into the way ASP.NET team work who are arguably among the most popular teams in Microsoft.

Downloading the source is all fine. Yet I had a few teething issues with getting it working which I share so that others having similar problems could find their way out.

Building the framework source code

OK, as soon as you have downloaded and unzipped the source, just open the solution. Since this source relies heavily on NuGet packages yet it does not contain binaries, it needs to re-download the packages. There are instructions on the page but I personally could not get it working. 

So first thing to do is to right-click on the solution and click on "Enable NuGet Package Restore" as below [UPDATE: You actually can ignore this step, and do not have to set this value. I managed to build without this step]:


Now, if you attempt to build, you will get the error below:

error : NuGet package restore is not currently enabled. For more information, please see: http://aspnetwebstack.codeplex.com/wikipage?title=NuGet+Packages

Solution is to go to Tools -> Options -> Package Manager -> Package source and add the address below:

http://www.myget.org/F/f05dce941ae4485090b04586209c8b08/
Now you need to rebuild the packages as advised in the ASP.NET web stack page:

build RestorePackages

And now finally rebuild the solution and this time it will work. As the link above describes, this NuGet feed is not quite official and is used for out of band releases - which this source code certainly is.

Now you might get this error again if you try rebuilding having added the new NuGet feed. Not to worry, delete the source code, unzip again, Enable NuGet Package Restore and then build. This time should work.

Using Web API Source code

One of the best ways to understand a source code is to see it running and debugging it. And that is what I tried to do. 

I had already installed ASP.NET Web API/MVC beta from the installer. So here is what I did: created an ASP.NET Web API project (see Part 1 for more details), added the project to the Web API source code, removed references to the ASP.NET Web API/MVC beta DLLs and added project reference to those DLLs I needed from its source. Easy! Well, not so fast...

The problem is if you have installed the ASP.NET Web API, all binaries are already GACed and they take precedence over the project references. You can verify this by looking at the list of DLLs loaded in the output window while debugging. Now this by itself is not a problem, but considering the source to be newer with breaking changes, it becomes a different matteeeerrr...

Now courtesy of Christoph De Baene, this also has a solution. I was lucky to find about his post just from yesterday as he was quicker to see the problem and find a solution. He explains about using Environment variable so CLR looks the development path first:

To resolve this problem we can use DEVPATH. It’s an environment variable that you can set to a folder (typically you’re output folder). The runtime will use the DEVPATH folder for probing before looking into the GAC!

Setting DEVPATH environment variable


You also need to add the entry below to your config file (app.config or web.config depending on your project):
 

 <configuration>
   <runtime>
      <developmentMode developerInstallation="true"/>
   </runtime>
 <configuration>
 
OK, now it is time to run the code. Well, I ended up using Christoph's code but still having issues this time "Method not found":

Method not found: 'Boolean System.Net.Http.Headers.HttpHeaders.TryAddWithoutValidation(System.String, System.String)'.

Well, it turns out this time that the version of the System.Net.Http DLL has also moved on and I used the one coming with the installer. However, while Microsoft has decided not to include this assembly's source code along with the rest, source has indeed moved on and you need to use the one in the packages folder underneath the solution.

Now I did that and still not working! I was pulling my hair out and went through a few things and realised references were not set to "Copy Local". Once I set that to true, it started working.

Conclusion

The process of building and running the ASP.NET Web API (and MVC) is a bumpy ride. There are quite a few additional things you have got to do to get it working.

In brief, here are the steps you need to do to be able to debug the source code if you have installed ASP.NET Web API beta installer (see above for details):
  1. Create a DEVPATH environment variable and set to your debug output folder
  2. Add an entry to your config to flag VS to use DEVPATH
  3. Make sure all your references are "copy local" set to true
  4. Make sure you add reference System.Net.Http.dll using "Manage NuGet packages" and not from the GAC

5 comments:

  1. I had a number of issues too, but I took a different path. I had major issues when using Enable Package Restore. I think you actually DON'T want to do that but rather do the BUILD RESTOREPACKAGES which should go out and get the NUGET pacakages. The source includes an alternate feed for some of the system components like System.net that are not on the regular NuGet feed.

    To run I create a new project in a new solution and hooked up to the Debug assemblies from the Web project. All of the required DLLs for MVC, Razor, Web Pages, System.net, Json.net etc. I used from there and that does work as long as you copy local - it'll override GAC'd instances.

    All that said it took me two tries to get the source installed and compiling. First time I thought I knew better and experimented with what I thought should work. Second time I followed the instructions from CodePlex EXACTLY and sure enough it worked.

    ReplyDelete
    Replies
    1. Hmmmm, interesting. It was such a frustrating journey that I was happy to do anything just to get it working!

      You might be right. I did not try the steps individually and I might have been unlucky to find the solution last hence had done a few unnecessary steps.

      I will try it out and update the post if I find any unnecessary steps.

      Thanks for stopping by.

      Delete
    2. I just tried all steps out and realised that "Enable NuGet Package Restore" is not required. Yet, I had to do all other steps for running the project.

      Delete
  2. Which config do you add DEVPATH to? Web.config or Machine.config. Trying to use it with web.config and .Net 4.0 doesn't seem to work. When I added it to the machine.config in C:\Windows\Microsoft.NET\Framework(&Framework64)\v4.0.30319\Config Visual Studio doesn't open.

    I appreciate your post and would be grateful if you could elaborate on the implementation of DEVPATH.

    ReplyDelete
    Replies
    1. DEVPATH is name of an environment variable you have to create and set to the debug folder of your build. Also you need to add

      <configuration>
      <runtime>
      <developmentMode developerInstallation="true"/>
      </runtime>
      <configuration>

      to your config file. I am updating the post now with more info on the DEVPATH

      Delete

Note: only a member of this blog may post a comment.