Quantcast
Channel: ASPNETWebStack Issue Tracker Rss Feed
Viewing all 7215 articles
Browse latest View live
↧

Commented Issue: Action invocation fails when attribute routing is used and trace is also enabled [1138]

July 19, 2013, 3:29 pm
$
0
0
I have a simple setup which contains ValuesController decorated with attributed routes. I am seeing the following error when tracing is __enabled__.

Attached a standalone katana selfhost repro.

__Configuration & Controller__:
```
public void Configuration(IAppBuilder appBuilder)
{
var config = new HttpConfiguration();

config.MapHttpAttributeRoutes();

config.EnableSystemDiagnosticsTracing();

appBuilder.UseWebApi(config);
}

[RoutePrefix("api/values")]
public class ValuesController : ApiController
{
[HttpGet("")]
public IEnumerable<string> GetAll()
{
return new string[] { "value1", "value2" };
}

[HttpGet("{id}")]
public string GetSingle(int id)
{
return "value";
}
}
```

__Error__:
```
{"Message":"An error has occurred.","ExceptionMessage":"The given key was not present in the dictionary.","ExceptionType":"System.Collections.Generic.KeyNotFoundException","StackTrace":" at System.Collections.Generic.Dictionary`2.get_Item(TKey key)\r\n at System.Web.Http.Controllers.ApiControllerActionSelector.ActionSelectorCacheItem.FindActionUsingRouteAndQueryParameters(HttpControllerContext controllerContext, ReflectedHttpActionDescriptor[] actionsFound) in c:\\WebstackRuntime\\Runtime\\src\\System.Web.Http\\Controllers\\ApiControllerActionSelector.cs:line 335\r\n at System.Web.Http.Controllers.ApiControllerActionSelector.ActionSelectorCacheItem.SelectAction(HttpControllerContext controllerContext) in c:\\WebstackRuntime\\Runtime\\src\\System.Web.Http\\Controllers\\ApiControllerActionSelector.cs:line 157\r\n at System.Web.Http.Controllers.ApiControllerActionSelector.SelectAction(HttpControllerContext controllerContext) in c:\\WebstackRuntime\\Runtime\\src\\System.Web.Http\\Controllers\\ApiControllerActionSelector.cs:line 38\r\n at System.Web.Http.Tracing.Tracers.HttpActionSelectorTracer.<>c__DisplayClass2.<System.Web.Http.Controllers.IHttpActionSelector.SelectAction>b__0() in c:\\WebstackRuntime\\Runtime\\src\\System.Web.Http\\Tracing\\Tracers\\HttpActionSelectorTracer.cs:line 51\r\n at System.Web.Http.Tracing.ITraceWriterExtensions.TraceBeginEnd(ITraceWriter traceWriter, HttpRequestMessage request, String category, TraceLevel level, String operatorName, String operationName, Action`1 beginTrace, Action execute, Action`1 endTrace, Action`1 errorTrace) in c:\\WebstackRuntime\\Runtime\\src\\System.Web.Http\\Tracing\\ITraceWriterExtensions.cs:line 375\r\n at System.Web.Http.Tracing.Tracers.HttpActionSelectorTracer.System.Web.Http.Controllers.IHttpActionSelector.SelectAction(HttpControllerContext controllerContext) in c:\\WebstackRuntime\\Runtime\\src\\System.Web.Http\\Tracing\\Tracers\\HttpActionSelectorTracer.cs:line 44\r\n at System.Web.Http.ApiController.ExecuteAsync(HttpControllerContext controllerContext, CancellationToken cancellationToken) in c:\\WebstackRuntime\\Runtime\\src\\System.Web.Http\\ApiController.cs:line 200\r\n at System.Web.Http.Tracing.Tracers.HttpControllerTracer.<ExecuteAsyncCore>d__5.MoveNext() in c:\\WebstackRuntime\\Runtime\\src\\System.Web.Http\\Tracing\\Tracers\\HttpControllerTracer.cs:line 88\r\n--- End of stack trace from previous location where exception was thrown ---\r\n at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)\r\n at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)\r\n at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()\r\n at System.Web.Http.Tracing.ITraceWriterExtensions.<TraceBeginEndAsyncCore>d__21`1.MoveNext() in c:\\WebstackRuntime\\Runtime\\src\\System.Web.Http\\Tracing\\ITraceWriterExtensions.cs:line 535\r\n--- End of stack trace from previous location where exception was thrown ---\r\n at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)\r\n at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)\r\n at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()\r\n at System.Web.Http.Dispatcher.HttpControllerDispatcher.<SendAsync>d__0.MoveNext() in c:\\WebstackRuntime\\Runtime\\src\\System.Web.Http\\Dispatcher\\HttpControllerDispatcher.cs:line 69"}
```

Comments: Fixed: https://aspnetwebstack.codeplex.com/SourceControl/changeset/cdf115d6198a38d08d5d773de7b71c27bbbe749b
↧
Search

Edited Issue: Action invocation fails when attribute routing is used and trace is also enabled [1138]

July 19, 2013, 3:29 pm
$
0
0
I have a simple setup which contains ValuesController decorated with attributed routes. I am seeing the following error when tracing is __enabled__.

Attached a standalone katana selfhost repro.

__Configuration & Controller__:
```
public void Configuration(IAppBuilder appBuilder)
{
var config = new HttpConfiguration();

config.MapHttpAttributeRoutes();

config.EnableSystemDiagnosticsTracing();

appBuilder.UseWebApi(config);
}

[RoutePrefix("api/values")]
public class ValuesController : ApiController
{
[HttpGet("")]
public IEnumerable<string> GetAll()
{
return new string[] { "value1", "value2" };
}

[HttpGet("{id}")]
public string GetSingle(int id)
{
return "value";
}
}
```

__Error__:
```
{"Message":"An error has occurred.","ExceptionMessage":"The given key was not present in the dictionary.","ExceptionType":"System.Collections.Generic.KeyNotFoundException","StackTrace":" at System.Collections.Generic.Dictionary`2.get_Item(TKey key)\r\n at System.Web.Http.Controllers.ApiControllerActionSelector.ActionSelectorCacheItem.FindActionUsingRouteAndQueryParameters(HttpControllerContext controllerContext, ReflectedHttpActionDescriptor[] actionsFound) in c:\\WebstackRuntime\\Runtime\\src\\System.Web.Http\\Controllers\\ApiControllerActionSelector.cs:line 335\r\n at System.Web.Http.Controllers.ApiControllerActionSelector.ActionSelectorCacheItem.SelectAction(HttpControllerContext controllerContext) in c:\\WebstackRuntime\\Runtime\\src\\System.Web.Http\\Controllers\\ApiControllerActionSelector.cs:line 157\r\n at System.Web.Http.Controllers.ApiControllerActionSelector.SelectAction(HttpControllerContext controllerContext) in c:\\WebstackRuntime\\Runtime\\src\\System.Web.Http\\Controllers\\ApiControllerActionSelector.cs:line 38\r\n at System.Web.Http.Tracing.Tracers.HttpActionSelectorTracer.<>c__DisplayClass2.<System.Web.Http.Controllers.IHttpActionSelector.SelectAction>b__0() in c:\\WebstackRuntime\\Runtime\\src\\System.Web.Http\\Tracing\\Tracers\\HttpActionSelectorTracer.cs:line 51\r\n at System.Web.Http.Tracing.ITraceWriterExtensions.TraceBeginEnd(ITraceWriter traceWriter, HttpRequestMessage request, String category, TraceLevel level, String operatorName, String operationName, Action`1 beginTrace, Action execute, Action`1 endTrace, Action`1 errorTrace) in c:\\WebstackRuntime\\Runtime\\src\\System.Web.Http\\Tracing\\ITraceWriterExtensions.cs:line 375\r\n at System.Web.Http.Tracing.Tracers.HttpActionSelectorTracer.System.Web.Http.Controllers.IHttpActionSelector.SelectAction(HttpControllerContext controllerContext) in c:\\WebstackRuntime\\Runtime\\src\\System.Web.Http\\Tracing\\Tracers\\HttpActionSelectorTracer.cs:line 44\r\n at System.Web.Http.ApiController.ExecuteAsync(HttpControllerContext controllerContext, CancellationToken cancellationToken) in c:\\WebstackRuntime\\Runtime\\src\\System.Web.Http\\ApiController.cs:line 200\r\n at System.Web.Http.Tracing.Tracers.HttpControllerTracer.<ExecuteAsyncCore>d__5.MoveNext() in c:\\WebstackRuntime\\Runtime\\src\\System.Web.Http\\Tracing\\Tracers\\HttpControllerTracer.cs:line 88\r\n--- End of stack trace from previous location where exception was thrown ---\r\n at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)\r\n at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)\r\n at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()\r\n at System.Web.Http.Tracing.ITraceWriterExtensions.<TraceBeginEndAsyncCore>d__21`1.MoveNext() in c:\\WebstackRuntime\\Runtime\\src\\System.Web.Http\\Tracing\\ITraceWriterExtensions.cs:line 535\r\n--- End of stack trace from previous location where exception was thrown ---\r\n at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)\r\n at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)\r\n at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()\r\n at System.Web.Http.Dispatcher.HttpControllerDispatcher.<SendAsync>d__0.MoveNext() in c:\\WebstackRuntime\\Runtime\\src\\System.Web.Http\\Dispatcher\\HttpControllerDispatcher.cs:line 69"}
```

↧
↧

Created Unassigned: In web api attribute routing, force users to supply HttpVerbAttribute base routetemplates on actions, if controller is decorated with RoutePrefix [1152]

July 19, 2013, 3:44 pm
$
0
0
__For the following case__:
```
[RoutePrefix("api/values")]
public class ValuesController : ApiController
{
public IEnumerable<string> GetAllValues()
{
return new string[] { "value1", "value2" };
}
}
```
Following is how the route looks like(_note_ that there are no httpMethod route constraints):
config.Routes.MapHttpRoute("routeName", "api/values", new { }, new { }, new { actions = [Values.GetAllValues()] });

__Reasons for this ask__:
1. In the above scenario, appropriate method constraint is not being added to the route.
2. Keeping the behavior consistent with how MVC attribute routing does, which is, it does not add any route to the collection if an action is not decorated with the verb attribute.
3. Also, I am seeing a NullRef exception when the controller looks like below:
```
RoutePrefix("api/values")]
public class ValuesController : ApiController
{
public IEnumerable<string> GetAllValues()
{
return new string[] { "value1", "value2" };
}

public string GetSingle(int id)
{
return "value";
}
}
```

__Exception__:
[NullReferenceException: Object reference not set to an instance of an object.]
System.Web.Http.HttpConfigurationExtensions.CreateRouteEntries(HttpControllerDescriptor controllerDescriptor) in c:\WebstackRuntime\Runtime\src\System.Web.Http\HttpConfigurationExtensions.cs:164
System.Web.Http.HttpConfigurationExtensions.MapHttpAttributeRoutes(HttpConfiguration configuration, HttpRouteBuilder routeBuilder) in c:\WebstackRuntime\Runtime\src\System.Web.Http\HttpConfigurationExtensions.cs:91
System.Web.Http.HttpConfigurationExtensions.MapHttpAttributeRoutes(HttpConfiguration configuration) in c:\WebstackRuntime\Runtime\src\System.Web.Http\HttpConfigurationExtensions.cs:63
MvcAppSample.WebApiConfig.Register(HttpConfiguration config) in c:\Users\kichalla\Documents\Visual Studio 2013\Projects\MvcAppSample\App_Start\WebApiConfig.cs:17
MvcAppSample.MvcApplication.Application_Start() in c:\Users\kichalla\Documents\Visual Studio 2013\Projects\MvcAppSample\Global.asax.cs:21
↧

Created Unassigned: Helpage UI to show the root request url path [1153]

July 19, 2013, 5:11 pm
$
0
0
A very minor user experience issue.

For the following controller:
```
[RoutePrefix("api/values")]
public class ValuesController : ApiController
{
[HttpGet("")]
[HttpGet("/")]
public IEnumerable<string> GetAll()
{
return new string[] { "value1", "value2" };
}
}
```
There would be 2 routes like below:
1. config.Routes.MapHttpRoute("routeName", "", new { }, new { httpMethod = HttpMethodConstraints[GET] }, new { actions = [Values.GetAll()] });
2. config.Routes.MapHttpRoute("routeName", "api/values", new { }, new { httpMethod = HttpMethodConstraints[GET] }, new { actions = [Values.GetAll()] });

__Issue__:
For the route '1', HelpPage UI says "GET". (__attached__ snapshot).

It would be clear if it said "GET /"
↧

Closed Issue: Remove fast path in UrlHelper.ODataLink once custom routes are supported [713]

July 19, 2013, 5:23 pm
$
0
0
From code comments:

// Fast path link generation where we recognize an OData path of the form "prefix/{*odataPath}".
// This is incredibly brittle code and should be removed whenever OData is upgraded to the next version
// The right long-term fix is to move this code to a new ODataRoute class that computes GetVirtualPath

Comments: No regressions
↧
↧

Commented Issue: Add support to attribute routing for ignoring the route prefix [1150]

July 19, 2013, 5:24 pm
$
0
0
AttributeRouting.net has an option for ignoring the route prefix:

```
[RoutePrefix("Prefix")]
public class IgnorePrefixController : Controller
{
[GET("Index")] // => "Prefix/Index"
[GET("NoPrefix", IgnoreRotuePrefix = true)] // => "NoPrefix"
public ActionResult Index() { /* ... */ }
}
```

It's really convenient to be able to add a route for an action without having to worry about existing route prefixes. This is like having absolute and relative URI paths.

Maybe we could use a leading slash as a way to indicate an absolute route path?:
```
[RoutePrefix("Prefix")]
public class IgnorePrefixController : Controller
{
[GET("Index")] // => "Prefix/Index"
[GET("/NoPrefix")] // => "NoPrefix"
public ActionResult Index() { /* ... */ }
}
```

Comments: Checked in: https://aspnetwebstack.codeplex.com/SourceControl/changeset/962c265473d77ec62dab3361886ca96178a8b886 https://aspnetwebstack.codeplex.com/SourceControl/changeset/5aedf25113a8c28af9e43ba9cd1247fd25ecabda
↧

Edited Issue: Add support to attribute routing for ignoring the route prefix [1150]

July 19, 2013, 5:24 pm
$
0
0
AttributeRouting.net has an option for ignoring the route prefix:

```
[RoutePrefix("Prefix")]
public class IgnorePrefixController : Controller
{
[GET("Index")] // => "Prefix/Index"
[GET("NoPrefix", IgnoreRotuePrefix = true)] // => "NoPrefix"
public ActionResult Index() { /* ... */ }
}
```

It's really convenient to be able to add a route for an action without having to worry about existing route prefixes. This is like having absolute and relative URI paths.

Maybe we could use a leading slash as a way to indicate an absolute route path?:
```
[RoutePrefix("Prefix")]
public class IgnorePrefixController : Controller
{
[GET("Index")] // => "Prefix/Index"
[GET("/NoPrefix")] // => "NoPrefix"
public ActionResult Index() { /* ... */ }
}
```

↧

Closed Issue: Direct link generation should be consistent with Url.Link when the OData path is empty and there is a route prefix [793]

July 19, 2013, 5:39 pm
$
0
0
The direct link generation generates "http://localhost/prefix/", while Url.Link generates "http://localhost/prefix" when the OData path is empty. There's a slight inconsistency here that we should fix.
↧
Search

Commented Unassigned: ObjectContent.Value to return T not object [1137]

July 20, 2013, 11:48 pm
$
0
0
Currently `ObjectContext<T>` returns `base.Value` which has type `object`.
Doesn't it make sense to introduce strongly-typed property to return `T` ( and change how is being kept internally)?
Comments: Currently `ObjectContext<T>` is useless because there is no difference between: T value = (T)((ObjectContext<T>)msg.Context)).Value and T value = (T)((ObjectContext)msg.Context).Value i.e. repeated cast takes place in both cases. Having a strongly-typed property of T would dispose from the necessity of such repeated cast.
↧
↧

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

July 21, 2013, 6:47 am
$
0
0
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
↧

Edited Issue: metadata uri (json light) is missing $select clause [1107]

July 21, 2013, 10:59 am
$
0
0
Spec here on the metadata url - http://docs.oasis-open.org/odata/odata/v4.0/csprd01/part1-protocol/odata-v4.0-csprd01-part1-protocol.html#_Toc355089421

Issue:
GET ~/Customers?$select=Name

Expected:

```
{
"odata.metadata":"http://localhost/$metadata#Customers&$select=Name","value":[
{
"Name":"Raghu"
}
]
}
```

Actual:

```
{
"odata.metadata":"http://localhost/$metadata#Customers","value":[
{
"Name":"Raghu"
}
]
}
```
The metadata URL describes the content of the payload and is really important in json light.
↧

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

July 21, 2013, 11:08 am
$
0
0
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.
↧

Commented Issue: NullPropagation option smart detection should handle ObjectContext and ObjectQuery [995]

July 22, 2013, 12:36 pm
$
0
0
We try to figure out whether we should do null propagation in query composition by looking at the QueryProvider of the IQueryable. We handle Linq2Objects, Linq2Sql and EntityFramework there.

For EntityFramework, we are only handling DbContext and DbSets. We should handle ObjectContext and ObjectQuery as well there.
Comments: [Fixed](https://aspnetwebstack.codeplex.com/SourceControl/changeset/4889738b40c8ba6913f6bd9bdd5316638e51189e).
↧
↧

Edited Issue: NullPropagation option smart detection should handle ObjectContext and ObjectQuery [995]

July 22, 2013, 12:36 pm
$
0
0
We try to figure out whether we should do null propagation in query composition by looking at the QueryProvider of the IQueryable. We handle Linq2Objects, Linq2Sql and EntityFramework there.

For EntityFramework, we are only handling DbContext and DbSets. We should handle ObjectContext and ObjectQuery as well there.
↧

Commented Issue: metadata uri (json light) is missing $select clause [1107]

July 22, 2013, 12:40 pm
$
0
0
Spec here on the metadata url - http://docs.oasis-open.org/odata/odata/v4.0/csprd01/part1-protocol/odata-v4.0-csprd01-part1-protocol.html#_Toc355089421

Issue:
GET ~/Customers?$select=Name

Expected:

```
{
"odata.metadata":"http://localhost/$metadata#Customers&$select=Name","value":[
{
"Name":"Raghu"
}
]
}
```

Actual:

```
{
"odata.metadata":"http://localhost/$metadata#Customers","value":[
{
"Name":"Raghu"
}
]
}
```
The metadata URL describes the content of the payload and is really important in json light.
Comments: [Fixed](https://aspnetwebstack.codeplex.com/SourceControl/changeset/a35d9185e8500641894e2689b41fe9971113961a).
↧
Search

Edited Issue: metadata uri (json light) is missing $select clause [1107]

July 22, 2013, 12:40 pm
$
0
0
Spec here on the metadata url - http://docs.oasis-open.org/odata/odata/v4.0/csprd01/part1-protocol/odata-v4.0-csprd01-part1-protocol.html#_Toc355089421

Issue:
GET ~/Customers?$select=Name

Expected:

```
{
"odata.metadata":"http://localhost/$metadata#Customers&$select=Name","value":[
{
"Name":"Raghu"
}
]
}
```

Actual:

```
{
"odata.metadata":"http://localhost/$metadata#Customers","value":[
{
"Name":"Raghu"
}
]
}
```
The metadata URL describes the content of the payload and is really important in json light.
↧

Commented Issue: Web API: Improve resolution of ApiController types [1075]

July 22, 2013, 12:41 pm
$
0
0
If an assembly A contains ApiControllers and it references another assembly B that does not contain ApiControllers and this assembly B is not found (because it is not installed for example) controller type resolution does not find the ApiControllers in assembly A.

In this case only a 404 status code is returned together with a HttpError message indicating that no matching controller for the specified route could be found. There is no indication __why__ this controller (that actually exists) has not been found.

For a developer who experiences this behaviour (lots of or even all routes return 404) this error is very hard to detect and to analyze. An improvement of either controller type resolution (prefered in my opinion) or at least error reporting or tracing would be very welcome.

Details about this problem are in this Stackoverflow question and its answers:

http://stackoverflow.com/questions/16812995/all-requests-to-asp-net-web-api-return-404-error

I'd like to mention that type resolution for MVC controllers does not suffer from this problem. MVC controllers in assembly A are found, even when assembly B is missing. It would be good in my opinion if controller type resolution in Web API would behave the same way.

Comments: Web API and MVC use the same method call to discover potential controller types: BuildManager.GetReferencedAssemblies()
↧
↧

Edited Issue: Provide HttpDirectRoute constructor which accepts HttpMessageHandler [1155]

July 22, 2013, 1:09 pm
$
0
0
__Scenario__:
User likes to register a per-route message handler for the Delete Customer action in the following controller.

```
[RoutePrefix("api/Customers")]
public class CustomersController : ApiController
{
[HttpDelete("{id}")]
public string Delete(int id)
{
return "DeleteCustomer with id " + id;
}
}
```

__Issue__:
HttpDirectRoute doesn't have a constructor which accepts HttpMessageHandler. I need this as the Handler property on HttpRoute (which HttpDirectRoute derives from) has a 'private set'

For reference, before the recent addition of HttpDirectRoute, we could add the per-route message handler like below:

```
public class CustomHttpRouteBuilder : HttpRouteBuilder
{
public CustomHttpRouteBuilder(HttpConfiguration configuration)
{
this.Configuration = configuration;
}

public HttpConfiguration Configuration { get; private set; }

public override IHttpRoute BuildHttpRoute(HttpRouteValueDictionary defaults, HttpRouteValueDictionary constraints, string routeTemplate)
{
if (defaults["controller"].ToString().ToLowerInvariant() == "customers" &&
defaults["action"].ToString().ToLowerInvariant() == "delete")
{
return new HttpRoute(routeTemplate, defaults, constraints,
dataTokens: null,
handler: HttpClientFactory.CreatePipeline(new HttpControllerDispatcher(Configuration),
new DelegatingHandler[] { new DeleteCustomerRouteDelegatingHandler() }));
}

return base.BuildHttpRoute(defaults, constraints, routeTemplate);
}
}
```

Register the custom route builder with configuration:
```
config.MapHttpAttributeRoutes(new CustomHttpRouteBuilder(config));
```

__Workaround__:
User has to create a custom route type deriving from HttpRoute, which accepts HttpMessageHandler and also mimic the functionality of HttpDirectRoute within it. User can then return the custom route type based instances when HttpRouteBuilder is building the routes.
↧

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

July 22, 2013, 1:12 pm
$
0
0
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: Hi, We ended up reverting the logic for the trailing slash because it causes exactly this type of confusion. We are instead making a change where if the route starts with "~/" it will ignore the various route prefixes. This way it is much more explicit. Thanks, Eilon
↧

Edited Issue: Helpage UI to show the root request url path [1153]

July 22, 2013, 1:14 pm
$
0
0
A very minor user experience issue.

For the following controller:
```
[RoutePrefix("api/values")]
public class ValuesController : ApiController
{
[HttpGet("")]
[HttpGet("/")]
public IEnumerable<string> GetAll()
{
return new string[] { "value1", "value2" };
}
}
```
There would be 2 routes like below:
1. config.Routes.MapHttpRoute("routeName", "", new { }, new { httpMethod = HttpMethodConstraints[GET] }, new { actions = [Values.GetAll()] });
2. config.Routes.MapHttpRoute("routeName", "api/values", new { }, new { httpMethod = HttpMethodConstraints[GET] }, new { actions = [Values.GetAll()] });

__Issue__:
For the route '1', HelpPage UI says "GET". (__attached__ snapshot).

It would be clear if it said "GET /"
↧
Viewing all 7215 articles
Browse latest View live
Search
<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>