WPF依赖属性所有者类型设为所属控件类时SetValue断点不触发问题

这是WPF依赖属性的设计特性，并非代码运行错误：

• 当你错误将依赖属性所有者类型填为typeof(string)时，WPF依赖属性系统无法在MyControl类型的依赖属性注册表中找到对应注册项，会 fallback 到CLR属性的set访问器执行赋值，因此你的断点可以命中。
• 当你修正为正确的typeof(MyControl)后，依赖属性系统找到了正确注册的依赖属性，此时XAML绑定场景下WPF会直接调用底层SetValue方法赋值，完全绕过CLR属性包装器的set块，因此断点不会触发。这是WPF的既定设计，CLR属性包装器仅提供给开发者手动调用代码、XAML初始化解析时使用，绑定、动画、样式赋值等场景都会直接操作依赖属性底层存储，不会走CLR包装器逻辑。

1. 不要把依赖属性的自定义变更逻辑写在CLR属性的set块中，正确的做法是在依赖属性注册时指定PropertyChangedCallback回调，示例代码如下：

public static readonly DependencyProperty MyPropertyProperty =
    DependencyProperty.Register(
        nameof(MyProperty), 
        typeof(string), 
        typeof(MyControl),
        // 新增属性变更回调
        new PropertyMetadata(default(string), OnMyPropertyChanged));

private static void OnMyPropertyChanged(DependencyObject d, DependencyPropertyChangedEventArgs e)
{
    // 拿到当前控件实例
    var control = (MyControl)d;
    // 在这里执行你原来写在set块里的逻辑
    control.PropertyChanged?.Invoke(control, new PropertyChangedEventArgs(nameof(MyProperty)));
}

// CLR包装器只保留最简的GetValue/SetValue调用，不要加任何额外逻辑
public string MyProperty
{
    get => (string)GetValue(MyPropertyProperty);
    set => SetValue(MyPropertyProperty, value);
}

2. 冗余逻辑清理：作为用户控件的对外依赖属性，本身已经自带WPF绑定需要的变更通知能力，如果你没有特殊的跨框架通知需求，不需要额外实现INotifyPropertyChanged接口，可以直接移除相关代码。
3. 如果你只是需要调试依赖属性的值变更，可以在Visual Studio中给SetValue方法打条件断点，或者直接在上述的PropertyChangedCallback回调中打断点即可命中。

内容的提问来源于stack exchange，提问作者mummy