-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
Support serialization of Microsoft.Extensions.Primitives.StringValues #1559
Comments
Are you able to implement a custom |
@scalablecory Maybe... I was worried I'd be opening a can of worms and writing 20 converters for something Json.Net already supported. |
@joshmouch out of curiosity, why are you serializing a FormFile? what is the output of newtonsoft serializing it? |
When I expose an Iformfile then generate a swagger client from it, the generated client excepts a Stream type. I have to include a custom type filter for Swashbuckler, though. |
@joshmouch - just curious.. what do you expect to happen with JSON serialization and |
@rynowak
|
That's pretty cool! I didn't realize that Autorest could do that. Do you have the full callstack of that exception? What part of the code is blowing up. I'm asking because I want to see if we can find a workaround to unblock you. |
Sure thing!
|
This callstack implies to me that this API returns an |
@rynowak , |
I had the same problem serializing Request.Headers (Microsoft.AspNetCore.Http.IHeaderDictionary). Luckily an extension method exists: var d = Request.Headers.ToDictionary(k=>k.Key, v=>v.Value); |
I have the same issue. Is there already a solution for this? |
The same error. |
I don't have this issue anymore. The problem was caused by what I RETURNED from the Controller method instead of the parameter of the method. For the input of the method I want to have the uploaded file IFormFile type, but also the meta data. So what I did was create a base class (CustomFile) with attributes like name and such. Then I created a subclass (UploadFile) that inherits from CustomFile and adds the IFormFile as a field. As the standard method to implement this is the POST method, the standard return is CreatedAtAction("GetCustomFile", ...). What I did here before was return the UploadFile - and this causes the error. But I don't want to return the file to the client, but just the meta data (CustomFile). When I changed that, error was gone. Does this help for you? I hope I explained it in a way you can understand it :) |
Hi, Is there any solution for this issue. I have .Net core app developed with 2.2 and Just update it with 3.1 and it breaks the working code. Following is the stack trace of error. Please suggest if any solution for this. System.NotSupportedException: The collection type 'Microsoft.AspNetCore.Http.IHeaderDictionary' on 'Microsoft.AspNetCore.Http.IFormFile.Headers' is not supported. |
@jigneshpclarion are you returning an IFormFile in your API method? That's not the way to return a file and might cause this issue. |
@mtirion - I'm not returning IFromfil in API method. Below is the API method code.
|
@jigneshpclarion what's the definition of the item? And are you sure it's failing on this method? Your stacktrace shows that there is an issue with the Microsoft.AspNetCore.Http.IFormFile.Headers. |
Before upgrading to .net core 3.1 following response returned by this method.
|
What happens when you do a JsonConvert in the method itself and return that as a string? Will that solve your problem? |
This following code fails for me even when it's empty class Test
{
public IList<IFormFile> file { get; set; }
}
...
var str = JsonSerializer.Serialize(new Test());
|
This works for me. Basically the FileInfo that consists of the upload file should NOT be returned to the CreatedAtAction method. |
thanks, it helped me. |
The issue here is that the element type StringValues is currently not supported for deserialization as it doesn't have a public parameterless ctor. Serialization of this type is supported. The serializer would need to implement a new convention where we check for ctors that take a T array (T[]). Moving to future as a custom converter can be written to handle this. |
The best way to resolve this while retrieving [Get] is to use the [JsonIgnore] attribute, class FileModel |
Note that |
This will better detect methods instantiated over unusable things.
Moving to 8.0 as we won't have time to fix this in 7.0 and there seem to be several workarounds for this |
Tagging subscribers to this area: @dotnet/area-extensions-primitives Issue DetailsI'm switching to System.Text.Json from Json.Net, and the following is no longer serializable: The exception is:
Will this be supported? Are there any workarounds?
|
We're moving this to Microsoft.Extensions.Primitives. We don't believe this is a good converter to add to System.Text.Json. Microsoft.Extensions.Primitives owner should consider adding JsonConverterAttribute on that class and provide converter. Otherwise it's a won't fix. |
@krwq if there is enough demand for this, then it makes sense to provide the converter in |
Tagging subscribers to this area: @dotnet/area-system-text-json, @gregsdennis Issue DetailsI'm switching to System.Text.Json from Json.Net, and the following is no longer serializable: The exception is:
Will this be supported? Are there any workarounds?
|
Both As already mentioned in this thread, we don't believe that this scenario is common enough to warrant OOTB support. Suggested workaround is writing a custom converter for |
If community is interested in us support this the right approach would be to create API suggestion with new library with JsonConverters and compile list of converters you'd like in there. If we were to support this as proposed here we'd need to take dependency just for this specific type or Microsoft.Extensions.Primitives.StringValues would need extra dependency on System.Text.Json which doesn't seem worth it. |
I'm switching to System.Text.Json from Json.Net, and the following is no longer serializable:
Microsoft.AspNetCore.Http.FormFile
The exception is:
Will this be supported? Are there any workarounds?
The text was updated successfully, but these errors were encountered: