MEF and FxCop rule PropertiesShouldNotBeWriteOnly

Mar 1, 2010 at 3:36 PM

I think it is a good idea to not expose the getter of a property decorated with [Import]. That way I enforce the intended usage of the property, i.e. dependency injection. However, I'm getting the PropertiesShouldNotBeWriteOnly warning from FxCop. I doubt the rule author has considered dependency injection, so I disagree with this FxCop rule.

Is there communication between the "MEF guys" and the "FxCop guys" about this? Can we expect the next version of FxCop to take MEF attributes into account?

Developer
Mar 1, 2010 at 6:09 PM

The FxCop rule only applies to public properties, in general it doesn't make a lot of sense to have a public property without a get method. For DI purposes you should make your write only properties internal/private.

Mar 1, 2010 at 6:34 PM

Siverlight being the exception with regard to making them public as we can't do private reflection in SL. An alternative approach there in order to "hide" the properties is to use explicit interfaces.

Mar 1, 2010 at 9:16 PM

@weshaggard: One of the advantages of dependency injection is that it gives you natural testing seams, making it fit perfectly with test driven development. Your suggestion would make it hard to inject mocks in a unit test, or to use the code outside of an IoC container in general.

@gblock: that would violate another FxCop rule.

In any case, I don't think that the code is wrong. I just posted here because I thought other MEF users might have experienced the same problem, and it might be a good idea to raise the issue with the FxCop team. Currently I just disable the FxCop rule, so I'm not looking for work-arounds.

Mar 11, 2010 at 4:32 AM

Having both worked on both the FxCop and MEF teams, and the team that owns the Framework Design Guidelines, I thought I would chime in.  ;)

It's unlikely we'll (we in this case, being Microsoft) change PropertiesShouldNotBeWriteOnly to ignore write-only properties marked with [Import] for a couple of reasons;

FxCop's original goal (which has somewhat deviated over the years) was about enforcing the Framework Design Guidelines and the form in which teams inside Microsoft ship reusable libraries to customers. Design rules such as PropertiesShouldNotBeWriteOnly and InterfaceMethodsShouldBeCallableByChildTypes aren't really designed to run over application code, where usability and reusability usually take a back seat to pragmatism and practicality.

The second reason, which is personal, is that I'm not sure I agree with your statement that DI properties should be write-only. Why, besides the dead code issue*, do you think you shouldn't providing a getter?

* By dead code issue, I mean, when no production code touches the getter.

Mar 11, 2010 at 11:28 AM
Edited Mar 11, 2010 at 11:29 AM
davkean wrote:

The second reason, which is personal, is that I'm not sure I agree with your statement that DI properties should be write-only. Why, besides the dead code issue*, do you think you shouldn't providing a getter?

* By dead code issue, I mean, when no production code touches the getter.

Isn't the dead code issue enough? But if you need another reason, I want to enforce that code in other classes does not access that public getter. Those classes should really be declaring their own MEF import if they need the same dependency.