Develop Reference

What is the point of auto generate instvar?

Since C# 3.0 there is the new syntax to autogenerate the instance variable from a propertie:
public string Foo { get; set; }
But there is no way to access the underlying backing field. So I don't really see the point of it because declaring the same instance variable would produce the same effect without the overhead of calling the "getter" and "setter".
public string Foo;
Declaring the property like:
public string Foo { get; }
or
public string Foo { set; }
is totally useless since we are not able to write resp. read the content of the field.
Does someone have a good explanation for why in C# they have put all this effort to introduce this syntactic sugar?
EDIT: People seems to think that I am confusing field and properties so let me clarify what I have said.
If you are using a property with auto generate field:
public string Foo { get; set; }
Then there is no point to it, since whenever you access the properties there is the overhead call to the get_Foo() "getter" every time you are accessing the properties and since your aren't doing anything particular in the the "getter" there is not mush interest of creating this property. Creating the field would have been exactly the same and it is mush faster (optimization wise).
Thanks

public string Foo { get; set; } defines a property.
public string Foo; defines a field.
They are different things. And the former is very convenient when you actually want a property and not a field.
As for accessing, you can define different access levels:
public string Foo { get; private set; }
See also Difference between Property and Field in C# 3.0+
As for your edit, what you are saying only makes sense if:
You are 100% sure that your property accessors will never contain any actual logic.
You are 100% sure that your field will never be data bound.
If any of the above is not true, then you need to define a property, even if that property seems like an empty stub.
Then, when later you decide to add logic to the accessors, you will not break all those clients that rely on your field being a field.
And if your class may be data bound, you need a property right away, as the data binding mechanisms ignore fields.

public string Foo;
Is a field.
public string Foo { get; set; }
Is a propery. They aren't the same thing, which has been discussed before. One of the mainly propagated advantages is the access control: get; private set; is used quite often as an example.
But there is no way to access the underlying backing field.
Yes there is, by calling the getter. Use [this.]Propertyname when you want to access it locally.
public string Foo { get; }
and
public string Foo { set; }
Will give you compiler errors, since you have to implement both get and set.

By itself it's pointless, but you can do things like this:
public string Foo { private set; get; }
Which has a lot more value.
Also properties and fields are not the same things.

The point of it is to make the code more concise and give you less to type.
In your example:
public string Foo;
Is a field and isn't the same as a property:
public string Foo { get; set; }
So the auto-property syntax has a use and is somewhat equivalent to:
private string _foo;
public string Foo { get { return _foo; } set { _foo = value; } }
However it doesn't create nice names, it uses safe names that would be invalid in C# (but are valid in IL).
Property overhead, though technically possible, is usually ironed out by the JIT into direct field access.
Properties are also usually the target for most data-binding frameworks. In reflection, a property differs from a field. WPF / WinForms data binding uses properties (not public fields). Most properties use a backing field to store the data. The trade-off is that when in the class, you use the property still as opposed to using the backing field. In practice, on release-optimized code, the performance is exactly the same as the JIT resolves them into exactly the same thing.

It makes defining properties faster and the code cleaner. If you don't need a property then don't define one - but I would recommend against public fields. You can make the property private and accessing it doesn't do anything more than returning the IL defined field. Further, if you need to do some work in the get or set then you'll have to define a backing value somehow, whether that be a field or some inherited member.

Property getter setter in C#

I have a class library project. I have a property there like below. It's not a read only property
private Int32 ABC ;
public Int32 ABCD
{
set
{
this.ABC = value;
}
get
{
return this.ABC;
}
}
My question is, Is it necessary to declare the private variable for the same and the getter / setter ?
EDIT
I mean could it be like below ?
public Int32 ABCD {}

Automatic property declarations require the get; set; statements in the braces (which is what you had in your original question):
public Int32 ABCD { get; set; }
An empty property block isn't valid.

Use auto-implemented properties introduced in C# 3.0 (VS 2008) or later.
http://msdn.microsoft.com/en-us/library/bb384054.aspx
public Int32 Abcd {get;set;}
The compiler creates the backing field for you. However it is anonymous and cannot be accessed. If later on you find the need to access the backing field, you can explicitly declare it and reimplement the getter and setter using that field without breaking your interface.

Use auto implemented property, It interduced from 2008 :
public Int ABCD
{
set;
get;
}
But difference is default value, i.e in property with backing field you can set a default value in variable but in this case default is .net defaults. (in fact you should initiate it in constructor for default value).

If you do the second choice, C# will create the first one for you.

Is it necessary to declare the private variable for the same and the getter / setter ?
If you mean is it necessary to use the private variable then yes, it is (unless you use the automatic method mentioned by BoltClock).You should keep in mind that it is a full code block, so you can do pretty much anything you like in there - although you should do it within reason, as you don't want anything that is going to slow down the access to the properties too much.
For example, there can be side effects to changing a property, i.e. another property may have to be updated, or you may have to notify that other properties have changed as well.
If you are not notifying or doing anything else, then the automatic getter/setter method is the quicker to develop (that is not claiming it is the fastest (or slowest) to execute though).

you can do like this
public string ABCD { get;set;}

Is there a technical reason why an automatic property must define both a get and set accessor

I know that automatic properties must define a get and set accessor method, I also know that it is possible for either of these accessors to be made invisible by means of an access modifier.
Is there a technical reason why the compiler is happy with
public object Property { get; set; }
but not
public object Property { get; }
My (possibly wrong) understanding of this code is that the compiler generates a backing field that is hidden from the calling code like so:
private object hiddenField; //hidden by compiler.
public object Property
{
get { return hiddenField; }
set { hiddenField = value;}
}
If the compiler can generate that, is there a reason that it can't omit the set accessor function based on the presence (or lack thereof) of a setter in the property declaration.
I understand that this may be an issue of feature scope rather than a technical limitation, I also freely admit that I have not yet consulted the C# language specification as yet.
[UPDATE 2]
Forgive me...I'm an idiot :P, I see now, thank you everyone for tollerating my senior moment/

Without the set accessor, there is no way to set the value, since you don't have a way to access "hiddenField".
Similarly, without a get accessor, there would be no way to get back a value you set.
Since it really becomes useless, it's not allowed.
However, you can have different accessibility on the two methods:
public object Property { get; private set; }
This provides you the ability to hide the set from outside, but still have a usable property.

public object Property { get; private set; }
will work, and it will have the semantics you expect it to.

How could you use a property such the following?
public object Property { get; }
Theoritically if you could write something like that it always returns null as it lacks to the set accessor. I think it is useless unless you set the hidden field in some way to have a static value to always return it.

From the C# spec:
Because the backing field is
inaccessible, it can be read and
written only through the property
accessors, even within the containing
type.
Leaving one of the accessors out would mean that the property would either be read-only or write-only, even within the constructor of the class/struct. Not very useful.

Auto-Implemented Properties c#

could someone explain me what's the idea behind using Auto-Implemented Properties c#?
public class Customer
{
public int ID { get; set; }
public string Name { get; set; }
}
I get the motivation to use properties for private field, so we can determine how one can access a private field. But here - it's just like defining the field to be public from the first place. no?
Is there a difference between defining a field to be "public const" or define it to have a get-only property ?

A public automatic property is not the same as a public field, they are not binary compatible. If you implement a public field and later on want to add some logic, you will have to change it into a property and thereby introduce a breaking change (because of the binary incompatibility). This is the reason why many conventions state that you should never expose public fields but rather use properties.
So, automatic properties are just a convenient starting point for any simple non-private class value member, allowing one to add logic later on while keeping binary compatibility.

Properties can be databound, whereas fields can not.

Automatically implemented properties are essentially syntactic sugar. Once compiled, the backing store exists. It just isn't available from the source code.
As others have stated, properties and fields are not equivalent. Fields and properties aren't compatible so changing between them is a breaking change. In addition, you cannot use data binding with fields.
Final point. Though in your case there's little functional difference between the example and a public field, you can change the visibility of one of the accessors. So, to create a read-only property using an automatic property, you may do something like:
public int ID { get; private set; }
In this case, the get accessor is public, as per the entire signature, but the set accessor is private.

I will let MSDN do the talking here....
"In C# 3.0 and later, auto-implemented properties make property-declaration more concise when no additional logic is required in the property accessors. They also enable client code to create objects. When you declare a property as shown in the following example (see MSDN article for example), the compiler creates a private, anonymous backing field that can only be accessed through the property's get and set accessors"
Probably the most advantageous difference is you can do pre/post validation, raise PropertyChanged events etc
Is there a difference between defining a field to be "public const" or define it to have a get-only property?
Yes, a get-only field must have a private field declaration. This field can be changed by the class internally, marking a field as const means it cannot be modified.

2: a public const has to be defined at compiletime, you cannot use reference objects for that. Only classes that inherit from System.ValueType (string, int, double, ...)
A const is also static whereas a property with only a getter is not (every class has it's own instance.)

Add logic to getter function. Can access values of another property
public string Status
{
get { return DeactivateDate != null ? "InActive" : "Active"; }
private set { }
}

Why can't properties be readonly?

This question came up in the comments of this answer. The inability to have readonly properties was proposed as a potential reason to use fields instead of properties.
For example:
class Rectangle
{
private readonly int _width;
private readonly int _height;
public Rectangle(int width, int height)
{
_width = width;
_height = height;
}
public int Width { get { return _width; } }
public int Height { get { return _height; } }
}
But why can't you just do this?
public int Width { get; readonly set; }
Edit (clarification): You can achieve this functionality in the first example. But why can't you use the auto-implemented property shorthand to do the same thing? It would also be less messy, since you wouldn't have to directly access the fields in your constructor; all access would be through the property.
Edit (update): As of C# 6.0, readonly properties are supported! object MyProp { get; } This property can be set inline (object MyProp { get; } = ...) or in the constructor, but nowhere else (just like readonly fields).

Because the language doesn't allow it.
This may seem like a frivolous answer: after all, the language designers could have declared that if you used readonly on an automatic property then it would mean "the property is settable but only in the constructor".
But features don't come for free. (Eric Gunnerson expresses it as "Every feature starts with minus 100 points.") To implement read-only automatic properties would have required additional compiler effort to support the readonly modifier on a property (it currently applies only to fields), to generate the appropriate backing field and to transform sets of the property to assignments to the backing field. That's quite a bit of work to support something that the user could do reasonably easily by declaring a readonly backing field and writing a one-line property getter, and that work would have a cost in terms of not implementing other features.
So, quite seriously, the answer is that either the language designers and implementers either never thought of the idea, or -- more likely -- they thought it would be nice to have, but decided there were better places to spend their finite resources. There's no technical constraint that prevents the language designers and implementers providing the feature you suggest: the reasons are more about the economics of software development.

If you want to make a property "read only" as far as functionality is concerned, you do so by only supplying the get method, as you indicated in your post.
public int Width { get { return _width; } }
public int Height { get { return _height; } }
The compiler will even reference these as "read only" if you try to write to them.
Having an additional term of readonly for a property would clash with also providing the set method. It seems to be poor syntax to me, i.e. how does the person reading it (or the compiler, for that matter) know what takes precedence: readonly or set?
Furthermore, as was explained in the answer you referenced, readonly applies only to fields and limits writing to those fields to the instantiation of the class. With properties, you can't write to them (I don't think) even within the constructor if they only have a get method.

You can make an automatic property read only by specifying the private access modifier for set like so
public bool Property {get; private set;}
The setter is still defined but it is no longer visible outside the class where the property is defined. As an aside, it is sometimes useful to define the setter as internal so that properties can be easily set from within the same assembly, but not by external callers.

Properties can be read-only, just not automatic properties.
Both get and set are required for automatic properties, and it makes no sense for a read-only property to have a set.
You can define a regular property as a read-only property by just defining the get - however, even if the requirement for both get and set for automatic properties didn't exist - the read-only property couldn't be automatically defined because you have to know the backing field to be able to set it's value internally (i.e. through the constructor).
I suppose there could be a template/macro or something defined in VS to generate the code this, but it couldn't be a part of the language itself.

I think fundamentally the problem is that properties are merely syntactic sugar for a field with optional getter/setter methods. Automatic properties generate the backing field so they require the "setter" or there would be no way to set the value of the backing field. Since properties really map onto methods, not fields, it doesn't make any sense to make them readonly.
Even if allowed, readonly could only apply to automatic properties. For traditional properties, you can put arbitrary code in both the getter and the setter. Even if the setter were able to be invoked only in the constructor of the class, the getter could still mutate the value based on whatever logic you decided to put in it. This would wholly inconsistent with the concept of readonly, thus necessitating different syntax rules and support for automatic/traditional properties. Since there is a mechanism -- using traditional properties with only a getter defined AND a readonly backing field as in the referenced question -- I see no point in mucking up the property syntax and potentially introducing confusion for something with a fairly easy and straightforward implementation using the current language constructs.

If the propert has a private set, then it is readonly from the outside world, i.e:
string _name;
public string Name
{
get{ return _name; }
private set { _name = value; }
}
Or, it can be made readonly if it doesnt have the setter at all, i.e.:
string _name;
public string Name
{
get{ return _name; }
}

In C# 6, auto properties can be readonly
https://learn.microsoft.com/en-us/dotnet/csharp/whats-new/csharp-6#read-only-auto-properties