UrlHelper returns swagger route instead of resource route

[ivanmartinvalle]

It seems that after installing Swashbuckle, UrlHelper starts returning all routes as a swagger route instead of the expected resource route. This caused us issues, as we rely on UrlHelper to set the Location header on POST requests.

HttpRequestMessage requestMessage = ...;
UrlHelper urlHelper = new UrlHelper(requestMessage);
var routeValues = new Dictionary<string, object> { {"Controller", "Users"}, {"userId", 10271992}};
var route = urlHelper.route(null, routeValues);
// Expected: "users/10271992"
// Actual: "swagger?Controller=Users&userId=10271992"

The issue comes from this line when relying on the default swagger-ui route.

Our current workaround is to configure a different route for swagger-ui

GlobalConfiguration.Configuration
                .EnableSwaggerUi("swagger/explorer/{*assetPath}", c => { 
                    // Our configuration 
                 } )

My questions:

• Is there a better work around that allows us to keep the same "/swagger" route for swagger-ui?
• Can this be documented somewhere, so someone else having the same issue can find the answer quickly (maybe this formal write-up of the issue is enough information to help someone out already)? I know it took us a non-trivial amount of time to track down the exact cause and an acceptable work around.

[domaindrivendev]

Interesting ... one way to get around this would be to pass a routeName instead of null to the route method. If you're using attribute routing, the value "DefaultApi" should suffice to scope the route lookup to just your API routes:

var route = urlHelper.Route("DefaultApi", new { controller = "users", userId = "123" });

If you're using traditional routing, you'll need to use the appropriate route name you've supplied when mapping your routes.

However, I can also fix this in Swashbuckle by constraining that specific route to be for UrlResolution only. See the following commit which will go out with the next release:

3e3a2c5

Thanks for pointing this out.

[domaindrivendev]

See 5.3.1