You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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:
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!
The text was updated successfully, but these errors were encountered:
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
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
usingRule
andIRuleObjectProvider
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:
.xaml
file: ExtendedApplicationRule.xaml..xaml
to C# using theRule
andIRuleObjectProvider
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
andIRuleObjectProvider
) 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
Let me know if there’s anything else you’d like to add or modify!
The text was updated successfully, but these errors were encountered: