0

I have a simple attribute route with three different path segments:

[HttpGet]
[GET("v{version:int}/{category}/{service}")]
public async Task<HttpResponseMessage> RouteMessage(
    string category, string service, int version = 1)
{
}

While the routing works when developing locally, it fails (404) when I deploy it to an IIS server.

The URL that fails:

http://example.com/v1/search/products?client=test

I'm certain it's not an IIS issue because I can still access the service using non-attribute routing (note that even though v1 isn't an int, the parameter itself has a default value):

http://example.com/api/route/?version=v1&category=search&service=products&client=test

I've installed Route Debugging and, as expected, my route does not match the attribute route even though it should.

The app-relative path is listed as ~/v1/search/products, which should match the url format v{version}/{category}/{service} ("version" is also correctly listed with an int route constraint).

Here's an image with the full debug info in case it helps.

[

nemec
  • 1,044
  • 9
  • 35
  • Do you see any error details in the 404 response? – Kiran Jun 20 '14 at 19:06
  • I do not. It's a generic 404 page, *not* a web api response: *Server Error / 404 - File or directory not found. / The resource you are looking for might have been removed, had its name changed, or is temporarily unavailable.* – nemec Jun 20 '14 at 19:14
  • Can you share in which order are you registering your routes? – Kiran Jun 20 '14 at 19:15
  • I'm using the default MapHttpRoute provided by WebApi. Attribute routing added a call to MapHttpAttributeRoutes *before* the WebApi route, so it should come first. I only have one Attribute Route, the one listed above. I'm fairly certain that the image I attached lists the routes in order too. – nemec Jun 20 '14 at 19:19
  • 1
    The thing which i want to get cleared about is whether you are calling `config.Routes.MapHttpAttributeRoutes` or `config.MapHttpAttributeRoutes`...this is because you seem to be using `AttributeRouting.Net` nuget package(based on your `GET` attribute) and not Web API's in-build attribute routing...so if you are mistakenly calling `config.MapHttpAttributeRoutes` (which belongs to webapi), then your attribute route is never created in the route table resulting in 404...i know you are mentioning that it works locally, but i want to make sure first.. – Kiran Jun 20 '14 at 19:23
  • I was calling `config.MapHttpAttributeRoutes`, not `config.Routes.MapHttpAttributeRoutes`. I will try using the other way and see if it helps. – nemec Jun 20 '14 at 19:39
  • Actually, I'm wrong. `config.MapHttpAttributeRoutes` was there, but AttributeRouting also added its own routing in a separate file using `WebActivator`. https://gist.github.com/nemec/b60dc023e1d5af905b4b – nemec Jun 20 '14 at 19:52
  • To confirm, you still see the issue..right? Finally, just to make sure that the problem is not with WebActivator(as i have seen users complaining similary here http://stackoverflow.com/questions/14115497/webactivator-preapplicationstartmethod-does-not-work), can you explicitly call `config.Routes.MapHttpAttributes()` and see if things still work? – Kiran Jun 20 '14 at 20:44
  • I did try explicitly calling it and still had the issue, but I ended up switching to the built-in WebApi routing. It's working fine now. Thanks for your help! – nemec Jun 20 '14 at 21:22

1 Answers1

1

Thanks to @Kiran Challa I realized that, although similar, the built-in WebAPI attribute routing is not the same as AttributeRouting.WebApi. I switched to the built-in routing and it all works fine now.

nemec
  • 1,044
  • 9
  • 35