Hello there visitor from grumpydev.com, if you are new here, you may want to subscribe this site.
Skip to content


403.14 Error When Trying to Access a WebAPI Route

Introduction

No, there’s no flying pigs, and Satan isn’t wearing a woolly hat, but this is a post about WebAPI (boooo!) I hit an “interesting” issue today, and felt a blog post was in order in case anyone else is bitten by this rather annoying “feature”.

I added a very simple route definition:

config.Routes.MapHttpRoute(
  name: "foo",
  routeTemplate: "{controller}/{name}",
  defaults: new { name = RouteParameter.Optional },
  constraints: new { controller = "foos" });

And a very simple controller:

namespace Bar
{
    using System.Web.Http;

    using Bar.Hypermedia;

    public class FoosController : ApiController
    {
        private readonly IFooService fooService;

        public FoosController(IFooService fooService)
        {
            this.fooService = fooService;
        }

        [HttpGet]
        public IEnumerable Root()
        {
            return this.fooService.GetFoos();
        }

        [HttpGet]
        public Foo Root(string name)
        {
            return this.fooService.GetFoo(name);
        }
    }
}

It couldn’t get much more simple – just a controller that returns a collection of Foos, or a single Foo, depending on whether the name of the Foo was specified. I fired up curl and getting a single Foo was fine, but browsing to /foos/ came back with:

HTTP Error 403.14 – Forbidden
The Web server is configured to not list the contents of this directory.

Err.. what?!

The Solution

The solution was easy – just ask a friendly neighbourhood ASP.Net WebAPI MVP to fix it for me 😉 Filip stepped up and confirmed all my code was fine, but after some head scratching noticed that I had my FoosController.cs inside a folder called Foos, and renaming that folder made the route work fine. It seems that if IIS/Asp.Net sees a folder that exactly matches the URL you’re asking for (/foos in this case) then it takes over and ignores any routes you have setup. Renaming folders would be a major pain in the backside, but luckily you can disable this behaviour by adding one line to the global.asax:

public class WebApiApplication : HttpApplication
{
    protected void Application_Start()
    {
        // Stop IIS/Asp.Net breaking our routes
        RouteTable.Routes.RouteExistingFiles = true;

        WebApiConfig.Register(GlobalConfiguration.Configuration);
    }
}

So many thanks to Filip for helping me solve this one – I’m sure I’d have lost time, and hair, trying to figure it out on my own. I’d consider this behaviour to be a bug, but I’m sure it’s actually a feature in someone’s mind. If only there was a better way to write HTTP APIs in .net…. 😉

Posted in .Net, ASP.Net, WebAPI.

Tagged with , , , .


Lowering The Barrier To Entry For Testing On Linux / Mono With Vagrant

Introduction

We are big fans of Mono on the Nancy project – we have Continuous Integration builds that run on both Mono 2.x, and Mono 3.x (in addition to Microsoft’s .net), and we have TravisCI also performing Mono builds of all pull requests as they come in.

As good as Mono is though, there are still times where we have issues with compatibility. Sometimes these are down to Mono itself, other times it’s a casing issue when running on Linux (which generally has a case sensitive file system, so /Images isn’t the same as /images). Plenty of our contributors are au fait with Mono and Linux, so fixing issues on pull requests isn’t an issue, but for those that aren’t, getting Mono and Linux set, even in a virtual environment can be daunting – and that’s before you even attempt to edit any files!

Introducing Nancy.Vagrant

I’ve discussed Vagrant in a previous post – it’s an excellent tool for automatically spinning up and configuring virtual machines, and we’ve used it to create two scripts that make creating a Linux/Mono test environment for Nancy as simple as typing:

vagrant up
vagrant ssh

And because Vagrant is capable of sharing folders between the host machine and the virtual machine, you can continue to edit the files in Visual Studio (or whatever editor of choice you use locally), and run the build in the Linux / Mono environment. Once you’re all done you can either stop the virtual machine, or delete it completely, using another single command.

Trying It Out

The scripts themselves, as well as instructions on getting up and running and some simple Linux help, can be found over on the Github repository:

https://github.com/NancyFx/Nancy.Vagrant

We hope this helps people get up and running easily with Linux and Mono, whether they’re contributing to Nancy or not.

Posted in Mono, Nancy, Vagrant, VirtualBox.

Tagged with , , , .


Windows 8, Hyper-V, VirtualBox, Vagrant and Hanging on Boot

 Introduction

I’ve recently been playing around with Vagrant to allow Nancy contributors to easily test their changes on Mono, even if they don’t have much (or any) experience with Linux or Mono itself (more on this soon). Vagrant allows scripts to be created to quickly and easily spin up virtuals with a certain configuration, and just as easily tear them down and destroy them when you’re done (which is just as important if you’re using a machine with limited SSD space).

Vagrant sits on top of actual Virtualisation software such as VirtualBox or VMWare (but no Hyper-V support), but it defaults to VirtualBox, and that’s the only provider out there that doesn’t involve spending money as both VMWare, and the Vagrant plugin for it, are commercial.

The Problem

Vagrant installed fine, VirtualBox installed fine, everything appeared to be working and could spin up VMs just dandy, but when I rebooted the machine I was stuck with the “spinning dots of doom”, and the only way to get the computer back was restoring from system restore and ditching VirtualBox 🙁

I tried 3 different machines, two failed the same way and the third worked fine; the only difference being the working machine didn’t have Hyper-V enabled in Win8, but I couldn’t remove it from the other two as it’s required for Windows Phone 8 development, and I use it for several other virtuals as the performance is excellent. Stuck between a rock and a hard place 🙁

The Solution

After trying multiple old versions of VirtualBox, and blind alleys that suggested disabling the hypervisor on startup would fix it (it didn’t), I finally tracked down the problem to be the networking drivers it installs. VirtualBox has three networking modes: NAT (the default), Bridged and HostOnly – with the latter two requiring separate drivers. Unchecking both sets of drivers in the installer and everything works fine:

VirtualBox

 

Vagrant uses NAT by default anyway, and that gives you internet access from the VMs, so there shouldn’t be too many situations where you need to use the other two options anyway. It even works side-by-side with Hyper-V too, so I can have my normal Hyper-V virtuals running while firing up Vagrant scripts on VirtualBox. It’s obviously a bit slower this way, as it can’t use it’s own HyperVisor, but it seems fast enough, and less hassle than having to disable Hyper-V and reboot every time I wanted to use Vagrant (or vice versa when I wanted to use Hyper-V).

Now, back to those Nancy scripts..

Posted in .Net, Misc, Nancy, Vagrant, VirtualBox.

Tagged with , , , , .


Could not load file or assembly FSharp.Core with .net 4.5 / NDjango / Win8

The Problem

With today’s release of the RTM versions of Win8 and Visual Studio 2012 I, like many others no doubt, have formatted one of my machines, thrown the new bits on, and kicked the tyres with some code. Unfortunately, when I tried Nancy, everything build just fine, but running any tests involving NDjango (F# based) blew up with:

Could not load file or assembly ‘FSharp.Core, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a’ or one of its dependencies. The system cannot find the file specified.

Or:

Could not load file or assembly ‘FSharp.Core, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a’ or one of its dependencies. The system cannot find the file specified.

All this works perfectly fine with .net 4, and .net 4.5 is supposed to be backwards compatible, but in this case it seems not. I haven’t done much digging, but if a strongly named assembly changes version between .net 4 and .net 4.5 I would expect an assembly binding to be in place to stop this kind of thing from happening – it’s possible that NDjango is doing something odd, but still, if it works in 4, it should work in 4.5.

This may or may not be an issue on Win7 if you’ve had .net 4 installed previously.

The Solution

Luckily, it’s very simple to add your own binding redirects to get things up and running again. These can either go in the app.config/web.config of your application, or you can put it in the machine.config – I wouldn’t recommend the latter though, as you may end up with an “it works on my machine” situation a few months down the line.

Either way, this is the section you need to add, it maps both 2.0.0.0 and 4.0.0.0 to the version that ships with .net 4.5/Win8 :

<assemblyBinding  xmlns="urn:schemas-microsoft-com:asm.v1">
    <dependentAssembly>
        <assemblyIdentity name="FSharp.Core" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
        <bindingRedirect oldVersion="2.0.0.0" newVersion="4.3.0.0"/>
        <bindingRedirect oldVersion="4.0.0.0" newVersion="4.3.0.0"/>
    </dependentAssembly>
</assemblyBinding>

A simple solution, and maybe this will just affect me, but this blog post will at least stop me from pulling my own hair out if this happens again 🙂

Posted in .Net, fsharp, Nancy.

Tagged with , , .


Nancy v0.8.0 – Best Laid Plans..

TL;DR

Nancy v0.8.0 is out, loads of cool new features such as static content (so you *finally* don’t have to do it yourself :-P), basic authentication support, and CSRF protection, and enhancements to things like error handling (with fancy pants error pages) and the test framework. We also have a fantastic new logo by Nicolas Garfinkiel (codetothepeople.blogspot.com), and a new website – so go check out the Nancy site now 🙂

The plan..

Once v0.7.1 was out of the way the plan was simple – work on diagnostics, hopefully interfacing with the guys from Glimpse, and get v0.8.0 – the “diagnostics release” out within 6 weeks or so. But things didn’t go entirely to plan…

A very nice problem to have..

We knew Nancy was getting a bit of a following, but we didn’t anticipate the level, and the quality, of the community contributions. We received lots of feedback, lots of great suggestions, and lots and lots of pull requests – before we knew it v0.8.0 was already looking pretty feature rich, without the diagnostics work we intended to be the core part of it, and time was tick tick ticking by. So, after a certain Mark Rendle started referring to this release as our “Duke Nukem Forever” release, we decided people had waiting long enough for an update and we “re-scoped” v0.8.0 so we could release the growing list of improvements sooner rather than later.

Taking a look at a GitHub comparison it shows v0.8.0 consisting of:

  • 186 commits
  • 226 files changed / updated
  • 19 different contributors
So 19 different people have contributed code to this release which, to me, is an amazing figure for an OSS project that’s not only relatively young, but also built using .net, which is frequently “bashed” by certain people for its alleged lack of community and its apparent “do what MS says to do”, sheep like mentality.

So, what *is* in v0.8.0?

You can see the commits that went into v0.8.0 in the GitHub comparison, or take a look at the issue list for a list of features / bug fixes, but some of the highlights are:

  •  Static content conventions – now static content is supported out of the box with pluggable conventions for which files are server from where.
  • CSRF protection – currently only supported in Razor, Spark and SSVE, but it’s now possible to validate  “tokens” (with or without a timeout) to protect your site against CSRF vulnerabilities. There’s a sample of this in the main ASPNet demo project.
  • The view cache should now be disabled in debug mode properly (yay!)
  • A new exception handling pipeline and built in error pages.
  • Basic authentication (as a new Nuget)
  • Protocol Buffers de/serialization support (as a new Nuget)
  • An awesome new logo (see below)
Plus plenty of other bug fixes, tweaks and behind the scenes changes.

Logo and website

Thanks to the efforts of Nicolas Garfinkiel (codetothepeople.blogspot.com) Nancy now has an awesome new logo – many thanks to Nicolas for the speed he put this together, and for putting up with Andreas and myself nitpicking so much 😉 You can see the new logo in “action” in the updated favicon, and on our newly launched Nancy site – go check it out!

Please note that we did have a redirect on that site, so if you get redirected to github you might have to press ctrl+enter (seems to work in Chrome) or clear your cache or restart your browser or something .. sorry 🙂

Thanks

So, a big thank you to everyone who contributed to this release – comments/suggestions, bug reports, fixes, features and even just giving kudos on Twitter – it’s all very much appreciated.

Now.. onwards and upwards to v0.9.0!

P.S. Andreas and I have recently recorded a Herding Code episode – so keep an eye (or ear) out for that.

Posted in .Net, Nancy.

Tagged with , , .