-
Notifications
You must be signed in to change notification settings - Fork 5.2k
[mono] Clean up internal usage of RuntimeComponents to always be treated as MSBuild Item
#91800
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
[mono] Clean up internal usage of RuntimeComponents to always be treated as MSBuild Item
#91800
Conversation
|
Tagging subscribers to this area: @directhex Issue DetailsThis PR cleans up the internal usage of This PR:
Follow-up tasks:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a welcome simplification. Thanks!
|
/azp run runtime-extra-platforms |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
/azp run runtime-extra-platforms |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
/azp run runtime-extra-platforms |
|
Azure Pipelines successfully started running 1 pipeline(s). |
0ec903e to
df3e41b
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! Thanks for refactoring and making this more straightforward.
src/libraries/System.Diagnostics.Tracing/tests/System.Diagnostics.Tracing.Tests.csproj
Outdated
Show resolved
Hide resolved
Co-authored-by: Ankit Jain <[email protected]>
Co-authored-by: Ankit Jain <[email protected]>
|
/azp run runtime-extra-platforms |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
Failures don't seem to be related |
This PR cleans up the internal usage of
RuntimeComponentswhere in some places it is used as a MSBuildPropertyand in others as anItem, which can lead to unexpected behaviours during app builds for bothAndroidandiOS-likeplatforms and additionally imposes unnecessary complication of treating them dually in different places.This PR:
*which previously meant to include all supported components (this was probably the reason to use aPropertyin the first place).BREAKING CHANGE- however I did not find any internal usage of said feature (I might be wrong though).UseAllRuntimeComponentsMSBuild property which when set totrueincludes all supported components by parsing theRuntimeComponentManifest.jsonfile and populatingRuntimeComponentsItem in_InitializeCommonPropertiestarget (in both:AppleBuild.targetsandAndroidBuild.targets)RuntimeComponentsto be treated as MSBuildItemdiagnostic tracingRuntimeComponentManifest.targetsfor local builds and testing to retrieve available runtime componentsFollow-up tasks:
AndroidSampleAppto useAndroidBuild.targetsdirectly instead of manually inferring build tasks and targets