2

I am using an attribute which should only be attached to properties with default accessors, and I am trying to enforce this coding convention programmatically.

This should be valid:

[Landing]
public int N {get; set;}

This should be invalid:

[Landing]
public int N {get {return n;} set{n=value+1;}}

How can I check that the code is valid, even if only at runtime?

Cœur
  • 37,241
  • 25
  • 195
  • 267
Alapago
  • 368
  • 2
  • 11
  • 1
    *Why* do you want that distinction? In particular, consider `public int N {get {return n;} set{n=value;}}` - the exact semantic equivalent of the automatically implemented version. Why should I not be able to specify the attribute on that? – Jon Skeet Mar 04 '14 at 10:25
  • 1
    I think this is what you are searching for: http://stackoverflow.com/a/2210327/3047078 – Flat Eric Mar 04 '14 at 10:28
  • 1
    possible duplicate of [How to find out if a property is an auto-implemented property with reflection?](http://stackoverflow.com/questions/2210309/how-to-find-out-if-a-property-is-an-auto-implemented-property-with-reflection) – Jon Mar 04 '14 at 10:29
  • 1
    I 'm also of the opinion that this is not a good idea. You can't possibly care about whether the property is auto-implemented or not; what your care about is something else. Tell us what that is and why you think this type of check is the way to achieve it. – Jon Mar 04 '14 at 10:31
  • My purpose is having AutoMapper ignore those properties. The use of an Automapper.IgnoreMap (=Landing) attribute is a workaround to not knowing an AutoMapper configuration option to ignore properties with setters. I agree that this might not be a good idea. – Alapago Mar 21 '14 at 11:45

2 Answers2

2

I don't think you can (without outrageous hacking). The whole point of properties is to hide the getter and setter implementation, so it is hidden.

Why the latter example is invalid? Maybe you could handle it as well? If not, have you considered using public fields instead of properties? These will always be standard.

Grzenio
  • 35,875
  • 47
  • 158
  • 240
  • It is possible, checking for the `CompilerGeneratedAttribute` as in the cited answer. The latter example is valid C# but should be invalid within my program (apologies for the ambiguity, I have now clarified the question). I am limited to using properties instead of fields because of the way this is going to be serialised. – Alapago Mar 21 '14 at 11:48
  • 1
    @user2046431, I guess you could check for both `CompilerGeneratedAttribute` and your `Landing` attributes in your serialization routine. Hardly elegant IMHO, but sometimes we don't have choice, hey :). Make sure you throw an exception when you get `Landing` attribute on an incompatible property though. – Grzenio Mar 21 '14 at 13:26
1

For an auto-property, the compiler just generates the backing field for you, so there's nothing special about an auto-property that you could discover at runtime.

You could try setting then getting the value to see if it's the same, but that's not going to prove that there's no extra code in the implementation.

For example, would you be okay if the setter fired an event before storing the value? There are lots of perfectly valid things a property implementation could do...

Jon G
  • 4,083
  • 22
  • 27
  • Actually there is, using `CompilerGeneratedAttribute` as in the cited answer. This is just to enforce a coding convention: when the getter is defined, use that particular attribute. – Alapago Mar 21 '14 at 11:53