You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The mechanism to infer binding source of API Controller action's parameters now mark parameters to be bound from the Dependency Injection container when the type is registered in the container.
In rare cases this can break applications that have a type in DI that is also accepted in API Controller actions methods.
Version
7.0.0-preview2
Previous behavior
Before if you want to bind a type registered in your Dependency Injection container, it must be explicitly decorated using an attribute that implements IFromServiceMetadata (eg.: FromServicesAttribute)
If the attribute is not specified, the parameter is resolved from the request Body sent by the client.
Services.AddScoped<SomeCustomType>();[Route("[controller]")][ApiController]publicclassMyController:ControllerBase{// Bind from the request body[HttpPost]public ActionResult Post(SomeCustomTypeservice)=> Ok();}
New behavior
Now types in DI will be checked at app startup using IServiceProviderIsService to determine if an argument in an API controller action will come from DI or from the other sources.
In the below example SomeCustomType (assuming you're using the default DI container) will come from the DI container.
Services.AddScoped<SomeCustomType>();[Route("[controller]")][ApiController]publicclassMyController:ControllerBase{// Binding from the services[HttpPost]public ActionResult Post(SomeCustomTypeservice)=> Ok();}
The new mechanism to infer binding source of API Controller action's parameters will follow the rule bellow:
A previously specified BindingInfo.BindingSource is never overwritten.
A complex type parameter, registered in the DI container, is assigned BindingSource.Services.
A complex type parameter, not registered in the DI container, is assigned BindingSource.Body.
Parameter with a name that appears as a route value in ANY route template is assigned BindingSource.Path.
All other parameters are BindingSource.Query.
Type of breaking change
Binary incompatible: Existing binaries may encounter a breaking change in behavior, such as failure to load/execute or different run-time behavior.
Source incompatible: Source code may encounter a breaking change in behavior when targeting the new runtime/component/SDK, such as compile errors or different run-time behavior.
Reason for change
We believe the likelihood of breaking apps to be very low as it's not a common scenario to have a type in DI and as an argument in your API controller action at the same time. Also, this same behavior is currently supported by Minimal Actions.
Recommended action
If you are broken by this change you can disable the feature by setting DisableImplicitFromServicesParameters to true.
Also, you could continue to have your action's parameters, with the new feature enabled or not, binding from your DI container using an attribute that implements IFromServiceMetadata (eg.: FromServicesAttribute).
Services.AddScoped<SomeCustomType>();[Route("[controller]")][ApiController]publicclassMyController:ControllerBase{// Binding from the DI container[HttpPost]public ActionResult Post([FromServices]SomeCustomTypeservice)=> Ok();}
Affected APIs
API Controller actions.
The text was updated successfully, but these errors were encountered:
Description
The mechanism to infer binding source of API Controller action's parameters now mark parameters to be bound from the Dependency Injection container when the type is registered in the container.
In rare cases this can break applications that have a type in DI that is also accepted in API Controller actions methods.
Version
7.0.0-preview2
Previous behavior
Before if you want to bind a type registered in your Dependency Injection container, it must be explicitly decorated using an attribute that implements
IFromServiceMetadata
(eg.:FromServicesAttribute
)If the attribute is not specified, the parameter is resolved from the request Body sent by the client.
New behavior
Now types in DI will be checked at app startup using
IServiceProviderIsService
to determine if an argument in an API controller action will come from DI or from the other sources.In the below example
SomeCustomType
(assuming you're using the default DI container) will come from the DI container.The new mechanism to infer binding source of API Controller action's parameters will follow the rule bellow:
BindingInfo.BindingSource
is never overwritten.BindingSource.Services
.BindingSource.Body
.BindingSource.Path
.BindingSource.Query
.Type of breaking change
Reason for change
We believe the likelihood of breaking apps to be very low as it's not a common scenario to have a type in DI and as an argument in your API controller action at the same time. Also, this same behavior is currently supported by Minimal Actions.
Recommended action
If you are broken by this change you can disable the feature by setting
DisableImplicitFromServicesParameters
to true.Also, you could continue to have your action's parameters, with the new feature enabled or not, binding from your DI container using an attribute that implements
IFromServiceMetadata
(eg.:FromServicesAttribute
).Affected APIs
API Controller actions.
The text was updated successfully, but these errors were encountered: