-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
WPF0041 is raised when setting the properties of private elements #356
Comments
We can tweak the rules and maybe we should make the default severity |
Configuring severity isn't an effective solution for us, alas. We have a library assembly where these warnings are welcome, but also many We would have to disable the warning for that project then re-enable it per file, which is prone to error, and then beyond that configure it per line in some cases. It would be much easier to turn it off entirely and then write a smarter version of our own that did the right thing by itself. |
You know you can configure per project using .editorconfig or .ruleset right? |
Yes, that's the exact operation that I'm talking about. I edited my previous comment for clarity. |
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:
FrameworkElement
class is setting the value of a public, writeableDependencyProperty
declared or inherited by that specific class itself.PropertyChangedCallback
is setting the value of any public, writeableDependencyProperty
.UserControl
orWindow
sets any of its own properties.The text was updated successfully, but these errors were encountered: