Short summary (3-5 sentences) describing the issue.
Currently the ODataResourceDeserializer::ReadInline calls
ODataResourceDeserializerHelpers.ApplyIdToPath which calls:
ODataUriParser parser = new ODataUriParser(readContext.Model, new Uri(serviceRoot), resourceWrapper.ResourceBase.Id);
without specifying the 4th argument - the IServiceProvider.
This is an issue as the custom ODataUriResolver can't be used from the IServiceProvider, and default one is being used causing issues down the line.
We are using Microsoft.AspNet.OData 7.7.5.0 version and updating to the latest version could be risky. We ask this to be fixed in 7.7.5.0 if possible. This is a backward compatible change, to take in IServiceProvider (default to null) in all public and protected methods of ODataResourceDeserializer and pass it down accordingly.
Assemblies affected
Which assemblies and versions are known to be affected e.g. OData .Net lib 7.x
Microsoft.AspNet.OData 7.7.5.0 +
Reproduce steps
The simplest set of steps to reproduce the issue. If possible, reference a commit that demonstrates the issue.
Create a custom ODataUriResolver and register it in IServiceProvider as ODataUriResolver.
Parse this URL:
/api/data/v9.0/systemusers(4cf0864c-c224-ef11-8408-0022480ac456)/Microsoft.Dynamics.CRM.RetrievePrincipalAccess(Target=@Target)?@Target=%7B%22%40odata.id%22%3A%22incidents(e21d1a87-1793-ef11-ac2d-6045bd09fcb8)%22%7D
Expected result
Custom ODataUriResolver needs to be called for both parts of the URL.
Actual result
Notice that the custom resolver is called for
systemusers(4cf0864c-c224-ef11-8408-0022480ac456)/
part but it is never called for
incidents(e21d1a87-1793-ef11-ac2d-6045bd09fcb8)
part (default one is called).
Short summary (3-5 sentences) describing the issue.
Currently the ODataResourceDeserializer::ReadInline calls ODataResourceDeserializerHelpers.ApplyIdToPath which calls: ODataUriParser parser = new ODataUriParser(readContext.Model, new Uri(serviceRoot), resourceWrapper.ResourceBase.Id); without specifying the 4th argument - the IServiceProvider.
This is an issue as the custom ODataUriResolver can't be used from the IServiceProvider, and default one is being used causing issues down the line.
We are using Microsoft.AspNet.OData 7.7.5.0 version and updating to the latest version could be risky. We ask this to be fixed in 7.7.5.0 if possible. This is a backward compatible change, to take in IServiceProvider (default to null) in all public and protected methods of ODataResourceDeserializer and pass it down accordingly.
Assemblies affected
Which assemblies and versions are known to be affected e.g. OData .Net lib 7.x Microsoft.AspNet.OData 7.7.5.0 +
Reproduce steps
The simplest set of steps to reproduce the issue. If possible, reference a commit that demonstrates the issue. Create a custom ODataUriResolver and register it in IServiceProvider as ODataUriResolver. Parse this URL: /api/data/v9.0/systemusers(4cf0864c-c224-ef11-8408-0022480ac456)/Microsoft.Dynamics.CRM.RetrievePrincipalAccess(Target=@Target)?@Target=%7B%22%40odata.id%22%3A%22incidents(e21d1a87-1793-ef11-ac2d-6045bd09fcb8)%22%7D
Expected result
Custom ODataUriResolver needs to be called for both parts of the URL.
Actual result
Notice that the custom resolver is called for systemusers(4cf0864c-c224-ef11-8408-0022480ac456)/ part but it is never called for incidents(e21d1a87-1793-ef11-ac2d-6045bd09fcb8) part (default one is called).