-
-
Notifications
You must be signed in to change notification settings - Fork 119
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
IEnumerable<> controller parameters do not bind from request body by default - Asp.net Core 8 #391
Comments
rizi
pushed a commit
to rizi/lamar
that referenced
this issue
Nov 23, 2023
…derIsService is used, in this case the model binder of aps.net core should create the object. Closes JasperFxGH-391
@jeremydmiller PR #392 fixes this issue. br |
rizi
pushed a commit
to rizi/lamar
that referenced
this issue
Nov 23, 2023
…derIsService is used, in this case the model binder of aps.net core should create the object. Closes JasperFxGH-391
rizi
pushed a commit
to rizi/lamar
that referenced
this issue
Nov 23, 2023
…derIsService is used, in this case the model binder of aps.net core should create the object. Closes JasperFxGH-391
jeremydmiller
added a commit
that referenced
this issue
Dec 14, 2023
…derIsService is used, in this case the model binder of aps.net core should create the object. Closes GH-391
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi,
When using a very simple MVC controller (not minimal api), the parameter of the method UpdateAsync (have a look at the sample below) will not be created by the model binder of asp.net but by lamar.
As far as I understand (after debugging Lamar) the issue is related to this code:
The method IsService (from Microsoft.Extensions.DependencyInjection.IServiceProviderIsService) in Lamar.IoC.Scope calls Lamar.ServiceGraph.CanBeServiceByNetCoreRules() and it returns true and I think that's the problem, in this case it should return false.
The question is: "is it possible for lamar to distinguish the different "use-cases" and return false in this case"?
To mitigate this problem you can add the [FromBody] Attribtute before the updateCommands parameter, like so:
However this can cause some additional work in our solutions (and with have quite a lot of them ;) ) and it should not be necessary, because complex types will normaly automatically be infered from the body.
There was a very similar issue by MS, but this has been fixed a while ago:
dotnet/aspnetcore#45162
Any help would highly be appreciated.
Sample to reproduce
The text was updated successfully, but these errors were encountered: