Q:

What is the difference between a property and a variable

I have a confusion about understanding Property and Variables
public class ABC()
{
    public int A;
    public int B { get; set; }
}

What is the exact difference between in A and B?

A:

As many have pointed out, A is a field, B is a property.
The real question is, why should you care, and what to use?
I refer to a blog post of Jonathan Aneja:
(Its in VB, but it applies to C# as well ;))
So why use properties over fields, 5 reasons:

1. Fields can’t be used in Interfaces
You can’t enforce the existence of a
field in an object’s public contract
through an interface. For properties
though it works fine.
2. Validation
While your application currently may
not require any validation logic to
set a particular value, changing
business requirements may require
inserting this logic later. At that
point changing a field to a property
is a breaking change for consumers of
your API. (For example if someone was
inspecting your class via reflection).
3. Binary Serialization
Changing a field to a property is a
breaking change if you’re using binary
serialization. Incidentally, this is
one of the reasons VB10’s
auto-implemented properties have a
“bindable” backing field (i.e. you can
express the name of the backing field
in code) – that way, if you change an
auto-implemented property to an
expanded property, you can still
maintain serialization compatibility
by keeping the backing field name the
same (in C# you’re forced to change it
because it generates backing fields
with unbindable names).
4. A lot of the .NET databinding infrastructure binds to properties but not fields
I’ve heard arguments on both sides as
to whether or not that’s a good thing,
but the reality is that’s the way it
works right now. (Note from me: WPF bindings work on properties)
5. Exposing a public field is an FxCop violation
For many of the reasons listed above
:)

There might be more reasons.
I would also like to point to a blog post of Jeff Atwood and conclude with a quote from it:

The really important thing to take away here is to avoid writing code that doesn't matter. And property wrappers around public variables are the very essence of meaningless code.

A:

A is a field, B is a property.  A property is basically syntactic sugar for getters and setters.  The class you have defined will be compiled into something like this:
public class ABC()
{
    public int A;

    private int backing_B;

    public void set_B(int value)
    {
        backing_B = value;
    }

    public int get_B()
    {
        return backing_B;
    }
}

Note that this kind of conversion is true for all C# properties -- accesses to ABC.B will be converted to method calls.  Properties basically provide the illusion of a "variable" while actually just being a cleverly disguised pair of methods.
This is important, because it allows you to declare your own get and set method body, which can validate values or do other interesting things:
private int b;

public int B {
    get { return b; }
    set {
        if (value < 0) throw new ArgumentOutOfRangeException("value");
        b = value;
    }
}

Note that most properties will use a field to store their value.  Properties seldom exist on their own, apart from fields.

A:

A property is sort of a short getter and or setter. You can add logic to the set or get of the property or make them private which means that they are not accessible from the out side, where a variable is always accessible (if it is public).

