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

Add a profile attribute to files in windows desktop runtime pack #4227

Merged
merged 3 commits into from
Mar 14, 2024

Conversation

LakshanF
Copy link
Member

@LakshanF LakshanF commented Mar 11, 2024

Adds a profile attribute to the RuntimeList.xml in windows desktop runtime pack, similar to the corresponding target pack. This is needed to fix issue 37088 and PR 39402 has the corresponding SDK fix.

The target pack uses System.Windows.Forms.FileClassification.props but the analyzer assemblies (System.Windows.Forms.Analyzers.CSharp.dll, System.Windows.Forms.Analyzers.dll) causes problems and hence the runtime pack uses the assembly names explicitly. Also, the runtime pack has extra assemblies than the target pack. The assembly, System.Private.Windows.Core.dll, isn't tagged with a profile.

@ViktorHofer
Copy link
Member

Isn't this possible without hardcoding all the assemblies?

@LakshanF
Copy link
Member Author

Isn't this possible without hardcoding all the assemblies?

This is mostly following the way target pack does this, and the runtime seems to have more files than the target pack. CreateFrameworkListFile that gets invoked via FrameworkListFileClass have validation mechanism to ensure that the content in RuntimeList.xml have the right profile tag.

Copy link
Member

@sbomer sbomer left a comment

Choose a reason for hiding this comment

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

I don't have an understanding of the framework generation logic, but since it sounds like the tooling will validate the list this LGTM. Thanks!

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.

4 participants