Skip to content

Support runtime packs with differing runtime IDs #12199

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

Merged
merged 1 commit into from
Jun 25, 2020

Conversation

sfoslund
Copy link
Member

@sfoslund sfoslund commented Jun 25, 2020

Bug fix for #11824
Fixes part of #12117

@sfoslund sfoslund changed the title Work around for runtime pack profiles with differing runtime IDs Support runtime packs with differing runtime IDs Jun 25, 2020
@sfoslund sfoslund requested a review from wli3 June 25, 2020 18:41
@wli3
Copy link

wli3 commented Jun 25, 2020

Thank you so much for look into it! This fix looks like right (the existing code is too long and convoluted and lack of tests. I cannot say it is good for sure). Let's unblock the insertion first.

@sfoslund
Copy link
Member Author

@wli3 thanks for taking a look, the tests I added here are ported directly from the ones that failed in installer. Does it make sense to check them in here and remove them in installer or should I take them out of this PR? Also do you want me to leave #12117 open to track adding more test coverage/ refactoring the code?

runtimePackForRuntimeIDProcessing = knownFrameworkReference.ToKnownRuntimePack();
includeInPackageDownload = true;
}
else
Copy link

Choose a reason for hiding this comment

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

this "else" I am not too sure. Is it the same logic before #11824 ?

@@ -139,5 +136,42 @@ private void AddItem(TestAsset testAsset, XElement item)
itemGroup.Add(item);
});
}

[WindowsOnlyFact]
public void ItCanPublishArm64Winforms()
Copy link

Choose a reason for hiding this comment

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

You can write unit test for this task like src\Tasks\Microsoft.NET.Build.Tasks.UnitTests\ProcessFrameworkReferencesTests.cs. It will be at least better for documenting this long class

if (knownFrameworkReference.Name.Equals(knownFrameworkReference.RuntimeFrameworkName, StringComparison.OrdinalIgnoreCase))
{
bool processedPrimaryRuntimeIdentifier = false;
// Only add runtime packs where the framework reference name matches the RuntimeFrameworkName
Copy link

Choose a reason for hiding this comment

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

Ideally these comments should be able to express in code. But meanwhile this class should really split into 4-5 class to make things clear. I will try to refactor that. (you should try too if you have time. reference http://arlobelshee.com/the-core-6-refactorings/)

@sfoslund
Copy link
Member Author

Merging now to get insertions going again, #12117 will track handling this PR feedback.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants