Skip to content
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

[release/5.0] DataContractSerialization doesn't work with TrimMode - link #42911

Merged
merged 2 commits into from
Oct 1, 2020

Conversation

github-actions[bot]
Copy link
Contributor

@github-actions github-actions bot commented Sep 30, 2020

Backport of #42824 to release/5.0

/cc @eerhardt

Customer Impact

DataContractSerializer doesn't work at all in an application that is trimmed with TrimMode=link. This includes Blazor WASM apps by default. It can also include any app that sets PublishTrimmed=true and TrimMode=link.

Customer reported, eg dotnet/aspnetcore#25909 (in Blazor) which shows up as a regression from earlier Blazor.

Testing

I tested the scenarios listed in both bugs logged for this issue, which were reading objects from a data stream:

#41525
#42754

I also tested that writing objects to a data stream works with trimming as well.

A new "trimming test" was added as well.

Risk

Low. This changes the way methods are discovered through Reflection in DataContractSerialization. Instead of doing its own filtering, it now uses the built-in Reflection APIs to find the method.

@eerhardt eerhardt changed the base branch from release/5.0-rc2 to release/5.0 September 30, 2020 18:35
@eerhardt eerhardt changed the title [release/5.0-rc2] DataContractSerialization doesn't work with TrimMode - link [release/5.0] DataContractSerialization doesn't work with TrimMode - link Sep 30, 2020
DataContractSerialization has some Reflection "shim" methods that the ILLinker can't see through. This causes critical methods to be trimmed and applications to fail. These methods were put in place in .NET Core 1.0 when the full Reflection API wasn't available.

The fix is to remove these "shim" Reflection APIs and use Reflection directly.

Fix #41525
Fix #42754
@@ -392,7 +392,7 @@ internal static bool IsNonAttributedTypeValidForSerialization(Type type)
else
{
return (type.IsVisible &&
type.GetConstructor(BindingFlags.Instance | BindingFlags.NonPublic | BindingFlags.Public, Array.Empty<Type>()) != null);
type.GetConstructor(BindingFlags.Instance | BindingFlags.NonPublic | BindingFlags.Public, null, Array.Empty<Type>(), null) != null);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it uncommon to use named parameters in this codebase?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No it isn't uncommon, but I'm not sure it adds a ton of value in these cases.

Note I've opened #42753 to make this overload an official API, so these nulls won't be necessary in the future.

@@ -38,7 +38,7 @@ private static MethodInfo ObjectEquals
{
if (s_objectEquals == null)
{
s_objectEquals = Globals.TypeOfObject.GetMethod("Equals", BindingFlags.Public | BindingFlags.Static);
s_objectEquals = typeof(object).GetMethod("Equals", BindingFlags.Public | BindingFlags.Static);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I realize this isn't new, but could we specify the parameter types in the GetMethod call?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can do that in the master branch with this follow up issue: #42861.

@danmoseley
Copy link
Member

@mconnew could you please sign off? should be a direct port of what you already approved.

@leecow leecow added Servicing-approved Approved for servicing release and removed Servicing-consider Issue for next servicing release review labels Oct 1, 2020
@danmoseley danmoseley merged commit b87e335 into release/5.0 Oct 1, 2020
@danmoseley danmoseley deleted the backport/pr-42824-to-release/5.0-rc2 branch October 1, 2020 17:43
@danmoseley
Copy link
Member

thanks!

@ghost ghost locked as resolved and limited conversation to collaborators Dec 7, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area-Serialization Servicing-approved Approved for servicing release
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants