I do not suggest doing this on your application but for testing purpose it may be usefull… Assuming you have: public class MyClass { public int MyNumber {get;} } You could do this if its for test purpose, I would not suggest to use this in your runtime code: var field = typeof(MyClass).GetField(“<MyNumber>k__BackingField”, BindingFlags.Instance | … Read more
No, you’ll have to use “traditional” property definitions for custom behavior.
From the C# Specification: 10.7.3 Automatically implemented properties When a property is specified as an automatically implemented property, a hidden backing field is automatically available for the property, and the accessors are implemented to read from and write to that backing field. [Deleted] Because the backing field is inaccessible, it can be read and written … Read more
You could check to see if the get or set method is marked with the CompilerGenerated attribute. You could then combine that with looking for a private field that is marked with the CompilerGenerated attribute containing the name of the property and the string “BackingField”. Perhaps: public static bool MightBeCouldBeMaybeAutoGeneratedInstanceProperty( this PropertyInfo info ) { … Read more
What’s happening here is the deserializer is trying to guess the name of your backing fields. You can solve this by adding explicit mappings (DataContract/DataMember attributes) like this: [DataContract] public class Cat { [DataMember] public string Name { get; set; } [DataMember] public string Breed { get; set; } }
Update – the answer below was written before C# 6 came along. In C# 6 you can write: public class Foo { public string Bar { get; set; } = “bar”; } You can also write read-only automatically-implemented properties, which are only writable in the constructor (but can also be given a default initial value): … Read more
Fields and properties look the same, but they are not. Properties are methods and as such there are certain things that are not supported for properties, and some things that may happen with properties but never in the case of fields. Here’s a list of differences: Fields can be used as input to out/ref arguments. … Read more
Automatic Properties are used when no additional logic is required in the property accessors. The declaration would look something like this: public int SomeProperty { get; set; } They are just syntactic sugar so you won’t need to write the following more lengthy code: private int _someField; public int SomeProperty { get { return _someField;} … Read more
We use them all the time in Stack Overflow. You may also be interested in a discussion of Properties vs. Public Variables. IMHO that’s really what this is a reaction to, and for that purpose, it’s great.
In a related question I had some time ago, there was a link to a posting on Jeff’s blog, explaining some differences. Properties vs. Public Variables Reflection works differently on variables vs. properties, so if you rely on reflection, it’s easier to use all properties. You can’t databind against a variable. Changing a variable to … Read more