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

Redefine in code using Rule and IRuleObjectProvider APIS all of the project property pages defined by the Project System in .xml #9630

Open
stmoor opened this issue Jan 14, 2025 · 1 comment
Assignees
Labels
Feature-Rules/Properties Triage-Investigate Reviewed and investigation needed by dev team

Comments

@stmoor
Copy link

stmoor commented Jan 14, 2025

Summary

The current method for extending/replacing the default project property pages in the Project System codebase is cumbersome and prone to errors, particularly when the method used to define the original property pages was .xaml, but the client needs to extend them in code instead. This request proposes that we refined the properties currently defined in .xaml using Rule and IRuleObjectProvider APIs to be aligned with how we defined the properties for standalone .NET Android, iOS and MAUI projects.

Details

This was an issue identified as a result of a bug fixed last year: Bug#2262240 - [MAUI] The project properties navigation menu has two Application pages. I have added more context explaining the root cause in the corresponding PR: [Bug#2262240] Fix duplicate Application property page.
I am including below some of the key details below.

Limitations of .xaml

From my limited understanding gained after talking with @tmeschter, the default Application page is defined via the ApplicationPropertyPage.xaml file in the Project System codebase. Due to the priority order in which rule definitions are evaluated, .xaml rules have higher priority than in code-defined rules. As a result, extending a .xaml rule with a code-defined one is not feasible since the .xaml rule will always take precedence.

Current Workaround

Currently, all MAUI-specific properties are defined in code (.cs files). To work around the limitation mentioned above, the following steps are taken:

  1. Extend the Application property page in a new .xaml file: ExtendedApplicationRule.xaml.
  2. Redefine all of the properties from the original Application properties and set their visibility to false as so to completely hide them.
  3. Define a new property page in code file, ApplicationRule.cs.
  4. Define all properties, including MAUI-specific ones, in this file, which includes manually redefining any default properties that were hidden in the previous step, so essentially translating them from .xaml to C# using the Rule and IRuleObjectProvider APIs.

Challenges

To my knowledge, there is no better way to hide all properties at once or override categories and their properties. In addition, each time a new property is added to any of the default property pages that are extended/customized for MAUI as it happened in the bug mentioned earlier, someone has to manually hide or redefine them in multiple places to avoid future bugs and unexpected behaviors.

Proposed Solution

Redefine all of the .xaml defined project property pages in the Project system using the available in code APIs (I.E., Rule and IRuleObjectProvider) as it results in enabling clients to more easily, efficiently extend, customize, hide those property pages, allowing for easier management and integration of MAUI-specific properties without the need for manual redefinition and hiding of properties.

User Impact

  • Simplifies the process of extending any Project System defined project property pages in the future.
  • Reduces the risk of errors and future bugs as there would be no need to coordinate updating code in two different codebases and in two different ways as the changes would automatically trickle down to any clients extending the update page. At most, a review to decide whether the property is relevant to MAUI projects and should be visible or not would be needed, but the process of hiding a property, if necessary, would be much simpler.
  • Reduces the risk of unexpected behaviors. The bug that uncovered this limitation was interesting because the behavior seen was not expected, which was the duplication of the Application page. With the proposed solution, this should happen as any new added properties to Application page should just automatically show up in the one customized version of it and work as expected even if we deem them not to be relevant to MAUI and hide them later.
  • Enhances maintainability of the MAUI project properties codebase such as by decreasing complexity and removing duplicated code.

Let me know if there’s anything else you’d like to add or modify!

@stmoor stmoor changed the title Redefine in code using Rule and IRuleObjectProvider APIS all of the project Properties defined by the project system in .xml Redefine in code using Rule and IRuleObjectProvider APIS all of the project property pages defined by the Project System in .xml Jan 14, 2025
@stmoor
Copy link
Author

stmoor commented Jan 14, 2025

@tmeschter Please let me know if you I missed anything as we discussed this a few months ago. Just to want to make sure I captured everything :)

@drewnoakes drewnoakes added the Triage-Investigate Reviewed and investigation needed by dev team label Jan 16, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature-Rules/Properties Triage-Investigate Reviewed and investigation needed by dev team
Projects
None yet
Development

No branches or pull requests

3 participants