Revert setter.value changes

[anjali-wpf]

Issue : #84

Reverted PRs : #745 and #9229

Description

Reverting a changeset that we've shipped in .NET 9 preview 7 to define Value property of Setter as XAML content property.

The above change increments internal indexing when creating the binary. When a customer installs a new version of the SDK, but the app still targets the old frameworks (.NET 8 and below), the binary created with the new SDK (with the new index information) is not understood by older runtime, which is why the below exception gets thrown.
System.Windows.Markup.XamlParseException with inner IndexOutOfRangeException: Index was outside the bounds of the array.

Customer Impact

All VS users using the new version of SDK and targeting old framework are unable to run their WPF applications. (BLOCKER)

Regression

Yes

Testing

Local VS testing

Risk

Low. Reverted functionality.

Microsoft Reviewers: Open in CodeFlow

[h3xds1nz]

No way this is being reverted once again :/

[lindexi]

Oh, bad news

[anjali-wpf]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[anjali-wpf]

/backport to release/9.0

[github-actions]

Started backporting to release/9.0: https://github.com/dotnet/wpf/actions/runs/10419998191

[anjali-wpf]

/backport to release/9.0-rc1

[anjali-wpf]

/backport to release/9.0-preview7

[github-actions]

Started backporting to release/9.0-rc1: https://github.com/dotnet/wpf/actions/runs/10420009398

[github-actions]

Started backporting to release/9.0-preview7: https://github.com/dotnet/wpf/actions/runs/10420010377

[miloush]

So what is the learning here, are we banning adding ContentProperty attribute to existing classes for backwards compatibility reasons?

[pchaurasia14]

So what is the learning here, are we banning adding ContentProperty attribute to existing classes for backwards compatibility reasons?

Absolutely not. We need to figure out a better way to manage the compat scenario. In fact, this issue won't be limited to just ContentProperty, but anytime we decide to add new things for PresentationBuildTasks (like x:bind support and more), we will run into the same scenario again.

Right now, given the blocking nature of the issue and the immediate release deadline, we had to make this choice.

We will figure out a way to isolate SDK dependencies with PresentationBuildTasks involved moving forward.

[h3xds1nz]

@pchaurasia14 Happy to hear that; this should also mean that PBT could get rid of .NET 4.7.2 targeting, correct?

[pchaurasia14]

PBT could get rid of .NET 4.7.2 targeting?

@h3xds1nz - I'm not sure about that yet. During our investigation, we found out that VS uses net472 version of PBT during WPF appl build (even when it is building for dotnet). I am unclear what risk would our removal (for targeting 472) create. My assumption was that net472 version was solely used during netfx appl builds. However, it looks like that's not the case.

But yes, we need to figure out how do we isolate such changes.

[h3xds1nz]

@pchaurasia14 Ouch, I see, thanks for the response. I also thought its just for netfx builds.

Hopefully we get there soon.

[singhashish-wpf]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[miloush]

PBT could get rid of .NET 4.7.2 targeting?

@h3xds1nz - I'm not sure about that yet. During our investigation, we found out that VS uses net472 version of PBT during WPF appl build (even when it is building for dotnet). I am unclear what risk would our removal (for targeting 472) create. My assumption was that net472 version was solely used during netfx appl builds. However, it looks like that's not the case.

cc @KirillOsenkov