ValidationResult Class

VR is not violating any guidelines here.  The guidelines do not say anywhere that you should never expose a public field (FxCop: 4.3.5).  The guidelines specify that if you need to expose a constant value (such as Success or Empty or Default) then you should prefer a static readonly field to a constant field (5.5).  The reasoning is beyond this scope.  Nevertheless this is the preferred approach to defining a constant object.  A property would provide no benefits over a readonly field in this case because the returned object is immutable and cannot be set.  The only benefit a property would give is that you could run some code when the property is accessed but what code would you run?  The only reasonable code is to initialize the field but since it is static readonly this only happens once and can be easily handled by the static ctor.  Maintainability-wise, since it is a static readonly field, the initialization can be modified in a future version and existing code is unaffected.  This is, perhaps, the biggest argument in favor of properties over fields but, again, in this case you can do so in the static ctor to accomplish the same behavior.

Why does Microsoft seem to violate its own espoused best practices for class design by exposing a public field? Why is Success a field when it could have been a property? I also see magic strings everywhere in System.ComponentModel.Design namespace arguments and usage. As a developer who is always trying to improve, it becomes very confusing to me when Microsoft constantly violates FxCop rules in its own libraries. It seems to be getting worse lately which sends conflicting messages.