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

Edited Issue: [OData] Add support for including non-key properties as well in the SelectExpand expression [1017]

July 17, 2013, 4:54 pm
$
0
0
We include the properties that the client has asked for (thorugh $select and $expand) and the entity keys in the projection expression we generate in the SelectExpandBinder.

If people customize their OData link generation, they might need to access to other properties as well. For example, lets say a Person entity has Id (key) and a Name, and, the generated links contain Name instead of Id.

We should add a setting on ODataQuerySettings to let people choose extra properties that they want to bring from their database.
↧
Search

Edited Issue: consider how nulls are represented with IEdmObject. [1014]

July 17, 2013, 4:54 pm
$
0
0
IEdmObject right now tracks entity instances only which are not nullable. Once, we add support for IEdmObject with complex types and collections, we have to figure out a way to represent null values as IEdmObjects. One strategy could be to have EdmNullValue that implements IEdmObject.
↧
↧

Edited Feature: Add support for Spatial Data types in OData [1010]

July 17, 2013, 4:54 pm
$
0
0
Currently, there is no support for spatial data types in Web API OData. Consider adding support for this as it makes impossible to develop any service that has to deal with spatial data.
↧

Edited Issue: '/', '\' and ' ' is not handled correctly in string primary key in edit link [498]

July 17, 2013, 4:54 pm
$
0
0
'/', '\' can't route to the correct action
' ' will be null value when binding to the id parameter.

Repro code:
public static void RegisterODataRoutes(this HttpConfiguration configuration)
{
// Metadata routes to support $metadata and code generation in the WCF Data Service client.
configuration.Routes.MapHttpRoute(ODataRouteNames.Metadata, "$metadata", new { Controller = "ODataMetadata", Action = "GetMetadata" });
configuration.Routes.MapHttpRoute(ODataRouteNames.ServiceDocument, string.Empty, new { Controller = "ODataMetadata", Action = "GetServiceDocument" });

// Relationship routes (notice the parameters is {type}Id not id, this avoids colliding with GetById(id)).
configuration.Routes.MapHttpRoute(ODataRouteNames.PropertyNavigation, "{controller}({parentId})/{navigationProperty}");

// Route for manipulating links.
//configuration.Routes.MapHttpRoute(ODataRouteNames.Link, "{controller}({id})/$links/Products");
configuration.Routes.MapHttpRoute(ODataRouteNames.Link, "{controller}({id})/$links/{navigationProperty}");

// Routes for urls both producing and handling urls like ~/Product(1), ~/Products() and ~/Products
configuration.Routes.MapHttpRoute("GetByStringId", "{controller}('{id}')");
configuration.Routes.MapHttpRoute(ODataRouteNames.GetById, "{controller}({id})");
configuration.Routes.MapHttpRoute(ODataRouteNames.DefaultWithParentheses, "{controller}()");
configuration.Routes.MapHttpRoute(ODataRouteNames.Default, "{controller}");
}

[EntitySetAttribute("todo")]
[DataServiceKeyAttribute("Name")]
public class Todo
{
[Key]
public string Name { get; set; }
}

public class TodoController : ApiController
{
static TodoController()
{
var todoes = new List<Todo>();
foreach (var c in "/ \\")
{
todoes.Add(new Todo()
{
Name = c.ToString()
});
}
Todoes = todoes;
}

public static IEnumerable<Todo> Todoes { get; set; }

public IEnumerable<Todo> Get()
{
return Todoes;
}

public Todo GetById(string id)
{
return Todoes.FirstOrDefault(t => t.Name == id);
}

[AcceptVerbs("Merge")]
public Todo Put(string id, Todo todo)
{
todo = Todoes.FirstOrDefault(t => t.Name == id);
return todo;
}
}

Client code:
[Fact]
public void TestSpecialCharacters()
{
DataServiceContext ctx = new DataServiceContext(new Uri(this.BaseAddress));
var todoes = ctx.CreateQuery<Todo>("todo").ToList();

foreach (var todo in todoes)
{
Uri selfLink;
Assert.True(ctx.TryGetUri(todo, out selfLink));
Console.WriteLine(selfLink);

ctx.UpdateObject(todo);

var response = ctx.SaveChanges().Single();

Assert.Equal(200, response.StatusCode);
}
}
↧

Created Unassigned: MVC attribute routing should generate unique route names automatically. [1146]

July 17, 2013, 6:05 pm
$
0
0
__Scenario__:
User decorates the controller and actions with attributed routes and expects the applicaiton to work.

__Issue__:
Consider the following two actions in AccountController(shortened for brevity):
```
[RoutePrefix("Account")]
public class AccountController : Controller
{
//
// GET: /Account/Register
[AllowAnonymous]
[HttpGet("Register")]
public ActionResult Register()


//
// POST: /Account/Register
[HttpPost("Register")]
[AllowAnonymous]
[ValidateAntiForgeryToken]
public async Task<ActionResult> Register(RegisterViewModel model)
}
```
After the above changes, when the application is launched, we currently get the following
__Error__:
"A route named 'Account/Register' is already in the route collection. Route names must be unique.
Parameter name: name"

__Expected__:
The above error should not be occuring and the application should be launched successfully.

__Reason__:
In MVC, it appears that most of the Url link generation happens via the "Url.Action" or "Html.Actionlink" helpers, where users can specify action name, controller name etc. Since these helpers are used more commonly than "Url.RouteUrl" which expects a route name, we should not force the users to supply a unique route name upfront. We should generate unique names automatically just like how Web API's attribute routing works.

Even in Web API, we do not expect the users to depend on our uniquely generated names to generate links. If indeed they would like to have a friendly name for a particular route, they are expected to explicitly supply them. This way at least we do not provide a bad user experience upfront like currently MVC attribute routing does.

↧
↧

Commented Issue: Expose the default logic of link generation to enable re-using logic. [536]

July 17, 2013, 6:52 pm
$
0
0
I agree that its easy to create links ourselves, but its natural and easier to just fallback to the default logic too.

Scenarios:
a. I would like to build a 'Transient' action on Product called "ExtendSupportDate". In my HasActionLink logic, I check to see if the given entity instance context(Product) is discontinued or not. if discontinued, i do not want to 'advertise' the action "ExtendSupportDate" otherwise I would like to re-use whatever logic the default Action link convention generates.
b. Similar as above, a scenario where you don't want to show Edit link for some entity instances and for the rest of them would want to use the default Edit link convention that we have.

Currently for scenario 'a', i am doing the following:
----------------------------------------------------------
static IEdmModel GetImplicitEdmModel()
{
ODataConventionModelBuilder modelBuilder = new ODataConventionModelBuilder();
var products = modelBuilder.EntitySet<Product>("Products");
var productFamilies = modelBuilder.EntitySet<ProductFamily>("ProductFamilies");
var suppliers = modelBuilder.EntitySet<Supplier>("Suppliers");

var config = products.EntityType.TransientAction("ExtendSupportDate");
config.Parameter<DateTime>("newDate");
config.ReturnsFromEntitySet<Product>("Products");
config.HasActionLink(eic =>
{
//Do not advertise 'ExtendSupportDate' for discontinued products
if(eic.EntityType.Name == "DiscontinuedProduct")
return null;

//Advertise for the rest of them
Product pd = (Product)eic.EntityInstance;

return new Uri(eic.UrlHelper.Link(ODataRouteNames.InvokeBoundAction, new {
controller = eic.EntitySet.Name,
boundId = pd.ID,
odataAction = "ExtendSupportDate" }));
});

return modelBuilder.GetEdmModel();
}
Comments: I have added a GenerateActionLink(this EntityInstanceContext entityContext, IEdmFunctionBase action) as a part of this [change](https://aspnetwebstack.codeplex.com/SourceControl/changeset/372edce5ceb0826aa73d90064df7671681198199),
↧

Edited Issue: Expose the default logic of link generation to enable re-using logic. [536]

July 17, 2013, 6:53 pm
$
0
0
I agree that its easy to create links ourselves, but its natural and easier to just fallback to the default logic too.

Scenarios:
a. I would like to build a 'Transient' action on Product called "ExtendSupportDate". In my HasActionLink logic, I check to see if the given entity instance context(Product) is discontinued or not. if discontinued, i do not want to 'advertise' the action "ExtendSupportDate" otherwise I would like to re-use whatever logic the default Action link convention generates.
b. Similar as above, a scenario where you don't want to show Edit link for some entity instances and for the rest of them would want to use the default Edit link convention that we have.

Currently for scenario 'a', i am doing the following:
----------------------------------------------------------
static IEdmModel GetImplicitEdmModel()
{
ODataConventionModelBuilder modelBuilder = new ODataConventionModelBuilder();
var products = modelBuilder.EntitySet<Product>("Products");
var productFamilies = modelBuilder.EntitySet<ProductFamily>("ProductFamilies");
var suppliers = modelBuilder.EntitySet<Supplier>("Suppliers");

var config = products.EntityType.TransientAction("ExtendSupportDate");
config.Parameter<DateTime>("newDate");
config.ReturnsFromEntitySet<Product>("Products");
config.HasActionLink(eic =>
{
//Do not advertise 'ExtendSupportDate' for discontinued products
if(eic.EntityType.Name == "DiscontinuedProduct")
return null;

//Advertise for the rest of them
Product pd = (Product)eic.EntityInstance;

return new Uri(eic.UrlHelper.Link(ODataRouteNames.InvokeBoundAction, new {
controller = eic.EntitySet.Name,
boundId = pd.ID,
odataAction = "ExtendSupportDate" }));
});

return modelBuilder.GetEdmModel();
}
↧

Closed Unassigned: Automatic routing implementation [1139]

July 17, 2013, 7:11 pm
$
0
0
Hello,

There is only one thing that I don't like about ASP.NET MVC - namely routing. Each time when I create a non-default controller action with non default parameter name I am supposed to manually enter new .MapRoute() instruction on RouteConfig.

I have created a NuGet package that solves this issue: https://nuget.org/packages/AutoRouting/
but I'm pretty sure that it can be done natively in ASP.NET MVC source code.

I'm not very familiar with ASP.NET MVC source code and unfortunately I don't have time now to address this issue and create a "pull request", but maybe someone will find a more "native" solution for this.

The whole scenario is described on project's github readme: https://github.com/sobanieca/AutoRouting/

Regards,
Adam Sobaniec
Comments: Hi Adam, this sounds cool but we're not sure it's a good fit for a core part of the MVC framework. We recommend that you continue figuring out the various odds and ends of the scenarios that you want to handle and get some more end-user feedback on this. We also recommend that you check out the new "attribute routing" feature in MVC: https://aspnetwebstack.codeplex.com/wikipage?title=Attribute%20routing%20in%20MVC&referringTitle=Specs It also makes some of these same cases easier to handle. Thanks, Eilon
↧
Search

Edited Issue: Currently if a HTTP method is not supported Web API returns a 404 instead of a 405 when there are actions for other supported methods [274]

July 18, 2013, 12:00 pm
$
0
0
In the current version of Web API, when the action selector does not find a matching action for a HTTP method it returns a 404 status code even when the resource URI supports other methods (e.g. it supports GET and POST but not DELETE, PUT, etc.)

Based on the HTTP spec, this is not the correct behaviour as a 404 means that "The server has not found anything matching the Request-URI". In this case, there is a resource at the Request-URI as an operation with a supported verb succeeds so a Not Found status code is misleading and incorrect. Instead, it should return a 405 status code which means "The method specified in the Request-Line is not allowed for the resource identified by the Request-URI". This is correct as only the particular method is not supported.
↧
↧

Edited Issue: 405 response should include an "accept" header [1129]

July 18, 2013, 12:01 pm
$
0
0
According to the spec for 405 errors, [10.4.6](https://tools.ietf.org/html/rfc2616#page-66):
> The response MUST include an Allow header containing a list of valid methods for the requested resource.

WebAPI doesn't include this header today.
↧

Edited Issue: WebAPI returning 405 in cases that should be 404 [1130]

July 18, 2013, 12:01 pm
$
0
0
Sometimes WebAPI returns 405 in cases where it should return 404. If there is no possible verb to satisfy a URL, then it should be 404.

Consider an empty controller:
class TestController : ApiController {
}

Today. calls to GET Api/Test will return a 405. It should be 404.

↧

Created Unassigned: Hiding controller from showing up on HelpPage does not work when attribute routing is used [1148]

July 18, 2013, 1:08 pm
$
0
0
__Scenario__:
User does not like to show up a controller on HelpPage (ex: EntitySetController in OData), so he would like to use setting like [ApiExplorerSettings(IgnoreApi=true)] on the controller.

__Issue__:
When AR is used, [ApiExplorerSettings(IgnoreApi=true)] on the controller is not being honored and HelpPage shows the controller. This is however not a problem when conventional routing is used though.

__Reason__:
With latest checkin related to bug # 1125, when ApiExplorer tries to generate descriptions it goes through different path for AR generated routes than conventional routes.

__Workaround__:
A user could set [ApiExplorerSettings(IgnoreApi=true)] on each individual action which can make the whole controller to not show up. But in case of EntitySetController, a user would have to override all the actions and do this, which is not a great experience, so we would need to fix this...

Attached a standalone katana selfhost repro.
Expected: "api descriptions count: 0"
Actual: "api descriptions count: 1"
↧

Edited Unassigned: Hiding controller from showing up on HelpPage does not work when attribute routing is used [1148]

July 18, 2013, 1:16 pm
$
0
0
__Scenario__:
User does not like to show up a controller on HelpPage (ex: EntitySetController in OData), so he would like to use setting like [ApiExplorerSettings(IgnoreApi=true)] on the controller.

__Issue__:
When AR is used, [ApiExplorerSettings(IgnoreApi=true)] on the controller is not being honored and HelpPage shows the controller. This is however not a problem when conventional routing is used though.

__Reason__:
With latest checkin related to bug # 1125, when ApiExplorer tries to generate descriptions it goes through different path for AR generated routes than conventional routes.

__Workaround__:
A user could set [ApiExplorerSettings(IgnoreApi=true)] on each individual action which can make the whole controller to not show up.

Attached a standalone katana selfhost repro.
Expected: "api descriptions count: 0"
Actual: "api descriptions count: 1"
↧
↧

Edited Issue: "Multiple actions found" error due to incorrect route created by attribute routing [1144]

July 18, 2013, 1:20 pm
$
0
0

__Scenario__:
User likes to support CORS for one of his actions and so he decorates the action with HttpPost and HttpOptions attributes.

Attached a standalone katana selfhost repro.

__Controller__:
```
[RoutePrefix("api/values")]
public class ValuesController : ApiController
{
[HttpPost("")]
[HttpOptions("")]
//[AcceptVerbs("POST", "OPTIONS", RouteTemplate = "")] //NOTE: THIS WORKS
public string Echo([FromBody]string value)
{
return value;
}
}
```
__Issue__:
When I am doing a POST to this action, I am receiving the following error:

{"Message":"An error has occurred.","ExceptionMessage":"Multiple actions were found that match the request: \r\nSystem.String Echo(System.String) on type SampleOwinApp.ValuesController\r\nSystem.String Echo(System.String) on type SampleOwinApp.ValuesController","ExceptionType":"System.InvalidOperationException","StackTrace":" at System.Web.Http.Controllers.ApiControllerActionSelector.ActionSelectorCacheItem.SelectAction(HttpControllerContext controllerContext)\r\n at System.Web.Http.Controllers.ApiControllerActionSelector.SelectAction(HttpControllerContext controllerContext)\r\n at System.Web.Http.ApiController.ExecuteAsync(HttpControllerContext controllerContext, CancellationToken cancellationToken)\r\n at System.Web.Http.Dispatcher.HttpControllerDispatcher.SendAsyncCore(HttpRequestMessage request, CancellationToken cancellationToken)\r\n at System.Web.Http.Dispatcher.HttpControllerDispatcher.<SendAsync>d__0.MoveNext()"}


__Reason__:
I noticed that the above problem is due to attribute routing creating route like below for the above action. __Note__ that the 'actions' datatoken has duplicate entries for the action 'Echo'.

config.Routes.MapHttpRoute("routeName", "api/values", new { }, new { httpMethod = HttpMethodConstraints[OPTIONS, POST] }, new { actions = [Echo(String value),Echo(String value)] });

__Workaround__:
Instead of using two attributes, user could just use the following attribute:
[AcceptVerbs("POST", "OPTIONS", RouteTemplate = "")]

In this case, the route being added would something like below:
config.Routes.MapHttpRoute("routeName", "api/values", new { }, new { httpMethod = HttpMethodConstraints[POST, OPTIONS] }, new { actions = [Echo(String value)] });
↧

Commented Issue: "Multiple actions found" error due to incorrect route created by attribute routing [1144]

July 18, 2013, 1:20 pm
$
0
0

__Scenario__:
User likes to support CORS for one of his actions and so he decorates the action with HttpPost and HttpOptions attributes.

Attached a standalone katana selfhost repro.

__Controller__:
```
[RoutePrefix("api/values")]
public class ValuesController : ApiController
{
[HttpPost("")]
[HttpOptions("")]
//[AcceptVerbs("POST", "OPTIONS", RouteTemplate = "")] //NOTE: THIS WORKS
public string Echo([FromBody]string value)
{
return value;
}
}
```
__Issue__:
When I am doing a POST to this action, I am receiving the following error:

{"Message":"An error has occurred.","ExceptionMessage":"Multiple actions were found that match the request: \r\nSystem.String Echo(System.String) on type SampleOwinApp.ValuesController\r\nSystem.String Echo(System.String) on type SampleOwinApp.ValuesController","ExceptionType":"System.InvalidOperationException","StackTrace":" at System.Web.Http.Controllers.ApiControllerActionSelector.ActionSelectorCacheItem.SelectAction(HttpControllerContext controllerContext)\r\n at System.Web.Http.Controllers.ApiControllerActionSelector.SelectAction(HttpControllerContext controllerContext)\r\n at System.Web.Http.ApiController.ExecuteAsync(HttpControllerContext controllerContext, CancellationToken cancellationToken)\r\n at System.Web.Http.Dispatcher.HttpControllerDispatcher.SendAsyncCore(HttpRequestMessage request, CancellationToken cancellationToken)\r\n at System.Web.Http.Dispatcher.HttpControllerDispatcher.<SendAsync>d__0.MoveNext()"}


__Reason__:
I noticed that the above problem is due to attribute routing creating route like below for the above action. __Note__ that the 'actions' datatoken has duplicate entries for the action 'Echo'.

config.Routes.MapHttpRoute("routeName", "api/values", new { }, new { httpMethod = HttpMethodConstraints[OPTIONS, POST] }, new { actions = [Echo(String value),Echo(String value)] });

__Workaround__:
Instead of using two attributes, user could just use the following attribute:
[AcceptVerbs("POST", "OPTIONS", RouteTemplate = "")]

In this case, the route being added would something like below:
config.Routes.MapHttpRoute("routeName", "api/values", new { }, new { httpMethod = HttpMethodConstraints[POST, OPTIONS] }, new { actions = [Echo(String value)] });
Comments: It is a bug. Fixed: https://aspnetwebstack.codeplex.com/SourceControl/changeset/2aa52f95ff7fcd75f21b32e007063b29487ad03a
↧
Search

Edited Issue: "Multiple actions found" error due to incorrect route created by attribute routing [1144]

July 18, 2013, 1:21 pm
$
0
0

__Scenario__:
User likes to support CORS for one of his actions and so he decorates the action with HttpPost and HttpOptions attributes.

Attached a standalone katana selfhost repro.

__Controller__:
```
[RoutePrefix("api/values")]
public class ValuesController : ApiController
{
[HttpPost("")]
[HttpOptions("")]
//[AcceptVerbs("POST", "OPTIONS", RouteTemplate = "")] //NOTE: THIS WORKS
public string Echo([FromBody]string value)
{
return value;
}
}
```
__Issue__:
When I am doing a POST to this action, I am receiving the following error:

{"Message":"An error has occurred.","ExceptionMessage":"Multiple actions were found that match the request: \r\nSystem.String Echo(System.String) on type SampleOwinApp.ValuesController\r\nSystem.String Echo(System.String) on type SampleOwinApp.ValuesController","ExceptionType":"System.InvalidOperationException","StackTrace":" at System.Web.Http.Controllers.ApiControllerActionSelector.ActionSelectorCacheItem.SelectAction(HttpControllerContext controllerContext)\r\n at System.Web.Http.Controllers.ApiControllerActionSelector.SelectAction(HttpControllerContext controllerContext)\r\n at System.Web.Http.ApiController.ExecuteAsync(HttpControllerContext controllerContext, CancellationToken cancellationToken)\r\n at System.Web.Http.Dispatcher.HttpControllerDispatcher.SendAsyncCore(HttpRequestMessage request, CancellationToken cancellationToken)\r\n at System.Web.Http.Dispatcher.HttpControllerDispatcher.<SendAsync>d__0.MoveNext()"}


__Reason__:
I noticed that the above problem is due to attribute routing creating route like below for the above action. __Note__ that the 'actions' datatoken has duplicate entries for the action 'Echo'.

config.Routes.MapHttpRoute("routeName", "api/values", new { }, new { httpMethod = HttpMethodConstraints[OPTIONS, POST] }, new { actions = [Echo(String value),Echo(String value)] });

__Workaround__:
Instead of using two attributes, user could just use the following attribute:
[AcceptVerbs("POST", "OPTIONS", RouteTemplate = "")]

In this case, the route being added would something like below:
config.Routes.MapHttpRoute("routeName", "api/values", new { }, new { httpMethod = HttpMethodConstraints[POST, OPTIONS] }, new { actions = [Echo(String value)] });
↧

Edited Issue: [AttributeRouting]Handle scenario when multiple route prefixes are used and there are explicit RouteNames on actions [959]

July 18, 2013, 2:01 pm
$
0
0
Currently the following would cause a problem, as we try to create 2 routes(one for each route prefix) with the same route name calle "GetSingleSample".

```
[RoutePrefix("api/test")]
[RoutePrefix("api/samples/test")]
public class SampleController : ApiController
{
[HttpGet("{id}", RouteName="GetSingleSample")]
public string Get(int id)
{
return "Get" + id;
}
}
```

__Error__:
A route named 'GetSingleSample' is already in the route collection. Route names must be unique.
Parameter name: name

__NOTE__:
1. This issue existing for MVC Attribute Routing too. We need to fix it there too.
2. Also while fixing this bug, we need to think of how can one generate Uri links based on particular route-prefixes too.
↧
↧

Edited Unassigned: Hiding controller from showing up on HelpPage does not work when attribute routing is used [1148]

July 18, 2013, 2:36 pm
$
0
0
__Scenario__:
User does not like to show up a controller on HelpPage (ex: EntitySetController in OData), so he would like to use setting like [ApiExplorerSettings(IgnoreApi=true)] on the controller.

__Issue__:
When AR is used, [ApiExplorerSettings(IgnoreApi=true)] on the controller is not being honored and HelpPage shows the controller. This is however not a problem when conventional routing is used though.

__Reason__:
With latest checkin related to bug # 1125, when ApiExplorer tries to generate descriptions it goes through different path for AR generated routes than conventional routes.

__Workarounds__:
1. A user could set [ApiExplorerSettings(IgnoreApi=true)] on each individual action which can make the whole controller to not show up.
2. A custom ApiExplorer deriving from the default and overriding the method "public override bool ShouldExploreAction(string actionVariableValue, HttpActionDescriptor actionDescriptor, IHttpRoute route)". This method would get called for every action that is going to be explored. One could check the controller name type from the supplied action descriptor and return 'false' for the ones not interested.

Attached a standalone katana selfhost repro.
Expected: "api descriptions count: 0"
Actual: "api descriptions count: 1"
↧

Closed Issue: $expand fails when the navigation property being expanded is null. [1043]

July 18, 2013, 4:03 pm
$
0
0
**Url**

`/api/passos?$expand=ProximoPasso&$select=Nome,ProximoPasso/Nome`

**Code**

```
public abstract class EntityNome : IEntity
{
public int Id { get; set; }
public string Nome { get; set; }
}
```

```
public class Passo : EntityNome, IAuditavel
{
public virtual Passo ProximoPasso { get; set; }
public virtual ICollection<Usuario> Responsaveis { get; set; }
public virtual ICollection<CheckListItemTemplate> CheckListItens { get; set; }
...
```

**Error**

```
{
"odata.error": {
"code": "",
"message": {
"lang": "en-US",
"value": "An error has occurred."
},
"innererror": {
"message": "Exception has been thrown by the target of an invocation.",
"type": "System.Reflection.TargetInvocationException",
"stacktrace": " at System.Web.Http.ApiController.<InvokeActionWithExceptionFilters>d__a.MoveNext()\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.Web.Http.Dispatcher.HttpControllerDispatcher.<SendAsync>d__0.MoveNext()",
"internalexception": {
"message": "The cast to value type 'Int32' failed because the materialized value is null. Either the result type's generic parameter or the query must use a nullable type.",
"type": "System.InvalidOperationException",
"stacktrace": " at System.Data.Entity.Core.Common.Internal.Materialization.Shaper.ErrorHandlingValueReader`1.GetValue(DbDataReader reader, Int32 ordinal)\r\n at lambda_method(Closure , Shaper )\r\n at System.Data.Entity.Core.Common.Internal.Materialization.Coordinator`1.ReadNextElement(Shaper shaper)\r\n at System.Data.Entity.Core.Common.Internal.Materialization.Shaper`1.SimpleEnumerator.MoveNext()\r\n at System.Data.Entity.Internal.LazyEnumerator`1.MoveNext()\r\n at System.Web.Http.OData.Query.ODataQueryOptions.LimitResults[T](IQueryable`1 queryable, Int32 limit, Boolean& resultsLimited)"
}
}
}
}
```
↧

Edited Unassigned: MVC attribute routing fails for multiple routes with the same URL, and no specific RouteName set. [1146]

July 18, 2013, 4:05 pm
$
0
0
__Scenario__:
User decorates the controller and actions with attributed routes and expects the applicaiton to work.

__Issue__:
Consider the following two actions in AccountController(shortened for brevity):
```
[RoutePrefix("Account")]
public class AccountController : Controller
{
//
// GET: /Account/Register
[AllowAnonymous]
[HttpGet("Register")]
public ActionResult Register()


//
// POST: /Account/Register
[HttpPost("Register")]
[AllowAnonymous]
[ValidateAntiForgeryToken]
public async Task<ActionResult> Register(RegisterViewModel model)
}
```
After the above changes, when the application is launched, we currently get the following
__Error__:
"A route named 'Account/Register' is already in the route collection. Route names must be unique.
Parameter name: name"

__Expected__:
The above error should not be occuring and the application should be launched successfully.

__Reason__:
In MVC, it appears that most of the Url link generation happens via the "Url.Action" or "Html.Actionlink" helpers, where users can specify action name, controller name etc. Since these helpers are used more commonly than "Url.RouteUrl" which expects a route name, we should not force the users to supply a unique route name upfront. We should generate unique names automatically just like how Web API's attribute routing works.

Even in Web API, we do not expect the users to depend on our uniquely generated names to generate links. If indeed they would like to have a friendly name for a particular route, they are expected to explicitly supply them. This way at least we do not provide a bad user experience upfront like currently MVC attribute routing does.

↧
Viewing all 7215 articles
Browse latest View live
Search
<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>