Uwp6.2: Port size on disk related fixes#31693
Uwp6.2: Port size on disk related fixes#31693zacharycmontoya merged 5 commits intodotnet:release/uwp6.2from
Conversation
MichalStrehovsky
commented
Aug 10, 2018
This corrects the size on disk regression caused by dotnet#19912. After that pull request, all of the schema validation stuff would always be included for any app that depends on System.Private.Xml because during initial analysis we consider a lot of things in S.P.Xml necessary as a precaution for SG generating references to it. The RD.XML in S.P.Xml then roots things forever. I spent some time getting a repro of the original failure and convinced myself this is not a scenario that would require RD.XML in the S.P.Xml assembly. Here's the facts: * This test uses a test hook to explicitly disable pregenerated serialization code for `XmlSchema`. (https://github.com/dotnet/corefx/blob/1afc5360013bedc4099875c836342f493b083e5f/src/System.Private.Xml/src/System/Xml/Schema/XmlSchema.cs#L175 that is on stack at the time of failure is an analysis slam dunk, so we do have pregenerated code, we just don't use it because of the hook) * The test is then testing the reflection fallback path to serialize `XmlSchema`. This doesn't work. Reflection fallback path won't in general work for _any framework provided type_ because there's no RD.XML to root it. Reflection fallback really only works for user types because of our default RD.XML that roots all user types (we also use that for the CoreFX tests, which is why the other reflection fallback tests don't hit issues).
This adds [removable feature annotation](dotnet/designs#42) to `XmlDownloadManager`. If the user specifies that they would like to remove support for this at publish/native compilation time, the linker/compiler is going to replace the method body of `CreateWebRequestOrThrowIfRemoved` with a throwing method body. The exception message is going to inform the user that the feature has been removed because they opted into the removal. Contributes to #30597. Saves 1.2 MB of the size of the Windows UWP People app. This is a size on disk regression that came with NetStandard 2.0.
…t#31533) This adds [removable feature annotation](dotnet/designs#42) to data contract serialization. If the user specifies that they would like to remove support for this at publish/native compilation time, the linker/compiler is going to replace the annotated method bodies with a throwing method body. The exception message is going to inform the user that the feature has been removed because they opted into the removal. The throwing method body is significantly smaller than the transitive closure of code reachable from the original method body. Contributes to #30597. Turning this feature off in the UWP People app saves 4% of size. This is a size on disk regression that came with the new version of CoreFX and blocks the Windows team in picking up the latest framework. There is a zero size growth goal.
This ports over the change from dotnet/corert@0ac83cb. When UsingResourceKeys is true and we stripped the resources, the existing code would have returned null.
|
cc @sergiy-k @zamont I'll make a separate pull request for Stephen's changes around System.Linq. Unfortunately that one cannot be cleanly cherry picked because there are merge conflicts and build breaks. |
| } | ||
| #endif | ||
|
|
||
| [RemovableFeature(ReflectionBasedSerializationFeature.Name)] |
There was a problem hiding this comment.
Should this RemovableFeatureAttribute be in an ifdef?
| // This code is statically reachable from any place that uses XmlReaderSettings (i.e. every app that | ||
| // does something XML related is going to have this in their transitive call graph). People rarely need | ||
| // this functionality though. | ||
| [RemovableFeature("System.Xml.XmlUrlResolver.NonFileUrlSupport")] |
There was a problem hiding this comment.
Should this RemovableFeatureAttribute also be in an ifdef?
|
The Linux x64 Release Build doesn't show any test failures in Jenkins, so I'm not sure why it returned as a failure. |
|
LGTM besides my two comments |
|
Turns out the Fedora.26.Amd configuration has reached end-of-life. I'll put that change on top of Morgan's existing PR and I hope that will be merged on Monday |
|
Morgan's PR was clean and is here for reference: #30886 |