Commented Unassigned: Url.Link is ignoring route prefix when generating route [1154]

I'm working with the nightly builds and hit a bug during url generation.

I'm leveraging the new CreatedAtRoute method to return a proper 201 response to the caller, and its internally using Uri.Link to generate the link to the given resource.

Here is the controller:

```
[RoutePrefix("accounts")]
public class AccountController : ApiController
{
[HttpGet("/{accountId}", RouteName = "GetAccount")]
public IHttpActionResult GetAccount(string accountId)
{
....
}

[HttpPost]
public IHttpActionResult CreateAccount(DTO.NewAccount account)
{
// Link generation happens here
}
}

```
The link I'm getting is http://localhost/1 instead of http://localhost/accounts/1 which should be the expected.

The other strange thing that happens is the route naming. IIRC there was a rule that when attribute based is used, you can use the <controllername>.<methodname> as route name parameter during link generation.

Now as I checked the route table I only saw Account1, Account2, Account3, etc route names, which is not giving the opportunity to generate routes by the convention above.

As a quick tip after I typed in the bug above something came into my mind. What is the url generation is just went wrong, because of the leading / in the method's url template, and I was right.

If I update the url template like this:

```
[HttpGet("{accountId}", RouteName = "GetAccount")]
```

then the generated url will be fine, although I still think that it should be working with a leading slash too, what do you think?

Thanks,
Attila
Comments: First, thanks for trying out our latest bits. We really appreciate it and are looking forward for this kind of feedback! Regarding your questions: 1. Generated Uri.Link : This is an expected behavior due to a change that was checked in couple of days back as part of fix for bug #1150. As part of this fix, having '/' prefix on a route template decorated on an action will ignore the route prefix attribute. 2. Route Names: We do not expect end users to depend on the auto-generated route names from attribute routing. Users can provide a more friendly route name and use it to generate the links.