Fix serialization of read-only IEnumerable's for DCS#42912
Fix serialization of read-only IEnumerable's for DCS#42912Anipik merged 1 commit intodotnet:release/3.1from
Conversation
|
This required porting over a missing resource string from .NET Framework. I'm not sure if that's permissible in a servicing fix. @terrajobst, can you answer this question or mention someone who can? |
Just saw this. @ericstj will know (I'm guessing the answer is either "no" or "not without special acts"). Can you avoid adding the string? |
|
Actually you should be able to service resources just fine in .NETCore. The reason we had special rules in .NETFramework was due to language packs. These ship separate installers for resource dlls vs implementation, so users can get in a state with updated implementation but not resource. So the resource dll would resolve but be missing the resource ID. Thus: no changes to resources in servicing on .NETFramework. In .NETCore we don't have language packs so its OK to change resources in servicing. |
...Private.DataContractSerialization/src/System/Runtime/Serialization/CollectionDataContract.cs
Outdated
Show resolved
Hide resolved
81784e9 to
4f2d4b0
Compare
Servicing change for dotnet/runtime#34151
Description
When a DataContractSerializer is created for an IEnumerable type without a default constructor, we should still be able to serialize the contents even though we can't instantiate an instance when deserializing. The silverlight implementation of DCS was originally ported which lacks this capability. This breaks serialization of the results from many LINQ queries.
The fix is to port the late throwing capability from .NET Framework.
Customer Impact
Internal customer is unable to port an existing .NET Framework WCF based service to CoreWCF.
Regression
This is a regression from .NET Framework. This is not a regression from earlier versions of .NET Core.
Testing
This includes a unit test which serializes a LINQ query result which returns a type without a default constructor.
Risk
Low. This is porting the existing implementation from .NET Framework. It's not introducing any new failure code paths as it turns a throw into a potential deferred throw. Existing happy code path is unaltered. Includes tests for the specific customer scenario.