Why does one implementation of binding to a property cause “Dependency property field missing” and not another?

Question

Many questions have been raised on this site and others regarding the "Dependency property field missing" false error that is generated by Resharper when using this implementation of binding to the Password property of a PasswordBox. Simply searching for the phrase with Google returns "About 8,550,000 results" at the time of this posting. There is also a bug report on it.

I recently found another implementation that does not generate the error, and I'm struggling to find the difference in that implementation that causes Resharper to not generate the false error.

The differences that I see:

1. The property that actually stores the password string (BoundPassword/Password) uses a FrameworkPropertyMetadata object in the second implementation instead of the standard PropertyMetadata object. But when I changed the first implementation to use this new type, I still got the error.
2. The first implementation performs casting prior to assigning in the property-changed handlers, whereas the second has both in the same statement. But this is just coding preference; the net result wouldn't change.

What am I missing?

Answer 1

The answer you looking for was given in RSRP-174487 issue comment 2 years ago - dependency/attached property field names should follow Microsoft notation - SomeNameProperty (have Property suffix) - to be correctly handled by ReSharper.

Dependency property registration is actually may be dynamic and performed at runtime, but this is really rare scenario and ReSharper still supports it by simply triggering of "Dependency property field missing" inspection off (Alt + Enter - Suppress inspection).

ReSharper is designed to deal with statically known dependency property registrations and validates existence of DP fields for you, but require you to follow Microsoft DP fields naming notation to work well. I think error message may be better, we will work on it.