Sunday, January 16, 2011

WCF REST IIS Hosting 404 Issue - RESOLVED!

Recently I've been mucking about in the WCF-REST arena and ran into an infuriating problem that kept me busy for almost three days.  Essentially I had created a small WCF REST service, and it worked fine when accessing it from VS2010 debugging, however why I tried to access the version I had published in IIS (IIS7 or IIS7.5) it would show me a 404 error, or the annoying "directory browsing not enabled" error.  Now you'd expect this on the old .NET 3.5 implementations of WCF REST, but in the newer environments you can do a .svc-less implementation of your service that is much cleaner and leads to a very straight-forward code to URL implementation.  I finally found a solution to my problem, and though it was one of those  embarrassingly obvious solutions, I could have gotten three days of my life back if someone would have mentioned their mistake.

Now if you do a Google search on "wcf rest iis hosting" you'll see that quite a few people have been having these issues, and there are answers out there ranging from making sure the AppPool user has the right permissions to ensuring that ASP.NET had been properly installed on IIS.  None of these suggestions worked for me, leading to quite a bit of frustration.  There was one small hint tucked away that eventually tipped me off to the real solution, however I didn't think to check it until today.  On Christopher Deweese's blog he has a great post discussing how to "do" WCF REST in .NET 4.0 and in the comments he mentions "You should not have a virtual folder set up for your paths. You should just deploy the service and let the routes be determined by the application (not at the IIS level)."  This is the key, in your  global ASAX file you'll have a line of code that looks like this: RouteTable.Routes.Add(new ServiceRoute("MyServiceName", new WebServiceHostFactory(), typeof(MyServiceType)));

Now, when you access this from the debugger you'll end up doing so from a URL similar to "http://localhost:[port]/MyServiceName/...", however once you publish your service to it's own IIS application under the Default Web Site you'll get the 404's starting to pop up again trying to access the URL "http://localhost/MyServiceName/..."  The answer to the problem becomes obvious when you notice that "http://localhost/MyServiceName/MyServiceName/..." works.  The "MyServiceName" string within your ServiceRoute(...) is being appended to the root of your application to determine the route to your service.  So to fix this you can simply publish your service to the root of its own site, or make your RouteTable declaration look like this:  RouteTable.Routes.Add(new ServiceRoute("", new WebServiceHostFactory(), typeof(MyServiceType)));

I hope this saves you a good bit of time in the future when trying to publish WCF REST to IIS7/7.5 and good luck with your future coding!

16 comments:

Anonymous said...

This isn't really a solution ... seems more like a glitch in the framework. Why shouldn't you be able to declare the virtual path to your service?

Jon said...

@Anonymous - Thanks for the input! I'm not sure I would categorize the behavior as a bug. Based on the API it looks to be more like an out-working of how MSFT chose to implement the simplifying the REST service URI's since it was originally introduced in WCF. So again, not so much of a bug, but more a "gotcha" of the way the feature was simplified.

Anonymous said...

Well it got me, and you have saved me days of frustration with your solution. Thanks mate, I am deeply grateful.

Jon said...

@Anonymous2 - Glad I could help!

Anonymous said...

Hi, I have deployed a wcf rest service using a virtual directory, so I think that this is not the problem

Shrikant Joshi said...

I am facing the same issue now.. I will try your solution. I was frustrated entire day yesterday..

But now I believe that you solution should work

CA said...

Thanks for this - like you I was stumped when I kept getting error 403.15 :-/ Out of habit, I place most of my stuff in virtual directories... this fixed it.

8 hours wasted (not 3 days... ;-)

Randall Sexton said...

This absolutely fixed the issue for me. Thanks!

PeteF said...

Thanks, your tip saved me hours!

Lalit said...
This comment has been removed by the author.
Lalit said...

In my case, I did not have "UrlRoutingModule" in the web.config and everything else was same.

Adding this section in web.config did the trick as mentioned in Chris' blog.

preetham l said...

Thanks mic that did work for me

Anonymous said...

Your a legend! - only wasted a few hours before finding this and that was painful enough. thanks

Anonymous said...

Thank you so much! This has been driving me crazy for 2+ days too until I found a link to your blog entry.

James said...

Just what I needed! This post is still saving us developers from frustration and headaches! Thank you for posting it. Let me know if you have an account at tippingcircle.com and I'll send you a tip for saving me hours of work. Thanks!

Jon said...

@James Thanks for the feedback! I sadly don't have a tippingcircle.com account, but I definitely appreciate the sentiment.

FYI: Check out App.net if you haven't already :).