URI parameter has null value in ODATA controllers

[GennadyGS]

When ODATA controllers have non-conventional names, action parameters, populated from URI, have null values.

Example (can be verified in ODataBasicSample):

    [ODataRoutePrefix( "People" )]
    public class PeopleNamesController : ODataController
    {
        [ODataRoute( "({id})/LastName" )]
        public IActionResult GetLastName( [FromODataUri] string id, ODataQueryOptions<Person> options ) =>
            Ok( new { LastName = $"{id ?? "null"}-lastName" } );
   }

Request:
http://localhost:1238/api/People(1)/LastName?api-version=1.0

Actual response:

{
    "lastName": "null-lastName"
}

Expected response:

{
    "lastName": "1-lastName"
}

Changing name of controller to PeopleController fixes the problem, however sometimes it is required to split big controller into several smaller ones. One of the reasons to do that is workaround to issue #336.

[fusionshen]

[ControllerName("People")]
[ODataRoutePrefix( "People" )]
public class PeopleNamesController : ODataController{...}

Do you try this?

[GennadyGS]

Thanks @fusionshen, ControllerName attribute works perfect as workaround for this particular issue. However, unfortunately, it does not resolve the issue #336, which I tried to resolve by splitting the controller class. It looks like classes with the same controller name are still considered as single controller by current logic.

[commonsensesoftware]

Thanks @fusionshen. You are correct.

@GennadyGS, the name of the controller is derived from the type name using the convention <Name>Controller. OData relies on mapping entity sets to the controller name. I'm not even sure that they can be different. Obviously if you split the versions across different types within the same namespace, they cannot have the same type name. This is exactly the scenario that ControllerNameAttribute was meant to solve. If you partition by namespace, then you can use the same name in each namespace. This is purely a style and preference.

#336 is definitely a bug. I believe I have it fixed and I expect to publish the fix sometime this week.

I'll leave this open for a few more days in case you want to reply; otherwise, this issue should be resolved. Thanks.

[GennadyGS]

Thanks for your answer, @commonsensesof.
It is actually up to you whether to treat this issue as a bug, it seems not so critical and has workaround.
However, please notice, that without aspnet-api-versioning, routing works correctly regardless of controller's class name and based only on ODataRoutePrefix and ODataRoute attributes. It seams reasonable, since all necessary information is already set in these attributes, so adjusting controller's class name seems redundant.
This behavior, in my opinion, also can lead to user's confusion, as it was in my case. Imagine user has working solution based on native Microsoft.AspNetCore.OData (using non-conventional controller's class name). Than he tries to apply aspnet-api-versioning and solutions stops working with such peculiar way as silently discarding values of action's parameters.

Thanks a lot for fixing #336. It is a really good news, looking forward into it.