The intent of this warning is to prevent data bindings from being unintentionally replaced with a local value, and that is a very helpful idea.
Unfortunately, the warning is raised in far too many bogus circumstances to actually be helpful. A UserControl/Window has complete control of the elements privately defined within its XAML file, and setting local values on them is a completely normal procedure. The author knows that the property is not bound, because if they didn't bind it then nobody did.
The warning can be bogus even in plain FrameworkElement types, since they can create and control their own private children.
When I added WpfAnalyzers to my company's large WPF codebase, it raised a whopping 533 WPF0041 warnings. 99-100% of these (it's hard to be sure, of course...) fall into one of the above categories. I would have to disable this warning entirely before committing anything to master.
My proposals are these:
- Raise WPF0041 when a
FrameworkElement class is setting the value of a public, writeable DependencyProperty declared or inherited by that specific class itself.
- Raise WPF0041 when an attached property's
PropertyChangedCallback is setting the value of any public, writeable DependencyProperty.
- Do not raise WPF0041 when a
UserControl or Window sets any of its own properties.
The intent of this warning is to prevent data bindings from being unintentionally replaced with a local value, and that is a very helpful idea.
Unfortunately, the warning is raised in far too many bogus circumstances to actually be helpful. A
UserControl/Windowhas complete control of the elements privately defined within its XAML file, and setting local values on them is a completely normal procedure. The author knows that the property is not bound, because if they didn't bind it then nobody did.The warning can be bogus even in plain
FrameworkElementtypes, since they can create and control their own private children.When I added WpfAnalyzers to my company's large WPF codebase, it raised a whopping 533 WPF0041 warnings. 99-100% of these (it's hard to be sure, of course...) fall into one of the above categories. I would have to disable this warning entirely before committing anything to master.
My proposals are these:
FrameworkElementclass is setting the value of a public, writeableDependencyPropertydeclared or inherited by that specific class itself.PropertyChangedCallbackis setting the value of any public, writeableDependencyProperty.UserControlorWindowsets any of its own properties.