`Rule.Default` is ignored for Launch Profiles

[JinShil]

Visual Studio Version

2022 Preview

Summary

I've created an IRuleObjectProvider for a custom Launch Profile following the guide at https://github.com/dotnet/project-system/blob/main/docs/repo/property-pages/how-to-add-a-new-launch-profile-kind.md. However, for any StringProperty or even IntProperty, the Default property is ignored.

Steps to Reproduce

1. Follow the steps in https://github.com/dotnet/project-system/blob/main/docs/repo/property-pages/how-to-add-a-new-launch-profile-kind.md to create a custom Launch Profile
2. Assign a value to a StringProperty.Default property.
3. Launch the Launch Profile UI in Visual Studio, select the launch profile, and notice that the fields are not populated with the default.

Expected Behavior

When creating a new Launch Profile using the IRuleObjectProvider API, and assigning values to the Default property of StringProperty and friends, when creating a new Launch Profile using the Visual Studio UI, then fields for each Rule should be populated with the value assigned to the Default property

Actual Behavior

The Visual Studio Launch Profile UI should populate the Rule fields with the value assigned to each rule's Default property.

User Impact

Users and developers are immensely annoyed.

[tmeschter]

@JinShil: Rule objects get used for many different purposes in CPS-based project systems, and not every use matches up cleanly with the properties available. The Rule in this case describes the UI to use for a particular launch profile and has no effect on the actual launch operation. That is, if Rule.Default were honored it would only be to show that value in the UI--it wouldn't actually be used at launch.

So while the project system could try to use Rule.Default there are at least three problems with doing so:

1. It would need to decide when to show the default instead of the actual value. Does it show if the underlying value is null, or the empty string, or a whitespace-only string, or some sentinel value, or some combination of these? And it would be necessary to consider how well this choice would work with all existing launch profile properties that might reasonably have a default.
2. To further complicate this much of the UI layer--including the translation of Rule objects into UI and flowing data to and from the underlying data sources--is shared with the project property pages, which are (generally) backed by MSBuild data rather than JSON data structures. Whatever was done to handle Rule.Default in launch profiles would need to work for that situation as well.
3. If you need to update the default value, this now needs to be done in two separate places--the Rule, and the code that supplies the default during the launch operation.

It's probably too late for the project system to go back and start honoring Rule.Default. However, this is an escape hatch: the ILaunchProfileExtensionValueProvider and IGlobalSettingExtensionValueProvider contracts can be used to intercept reads and writes of properties in a launch profile/global settings and manipulate the data in any way you see fit--including providing a default value. We don't have much documentation on these but I don't think they're any more complicated to use than the IRuleObjectProvider.