Properties vs Methods

Yes, if all you're doing is getting and setting, use a property.

If you're doing something complex that may affect several data members, a method is more appropriate. Or if your getter takes parameters or your setter takes more than a value parameter.

In the middle is a grey area where the line can be a little blurred. There is no hard and fast rule and different people will sometimes disagree whether something should be a property or a method. The important thing is just to be (relatively) consistent with how you do it (or how your team does it).

They are largely interchangeable but a property signals to the user that the implementation is relatively "simple". Oh and the syntax is a little cleaner.

Generally speaking, my philosophy is that if you start writing a method name that begins with get or set and takes zero or one parameter (respectively) then it's a prime candidate for a property.

From the Choosing Between Properties and Methods section of Design Guidelines for Developing Class Libraries:

In general, methods represent actions and properties represent data. Properties are meant to be used like fields, meaning that properties should not be computationally complex or produce side effects. When it does not violate the following guidelines, consider using a property, rather than a method, because less experienced developers find properties easier to use.

Searching through MSDN, I found a reference on Properties vs Methods that provides some great guidelines for creating methods:

• The operation is a conversion, such as Object.ToString.
• The operation is expensive enough that you want to communicate to the user that they should consider caching the result.
• Obtaining a property value using the get accessor would have an observable side effect.
• Calling the member twice in succession produces different results.
• The order of execution is important. Note that a type's properties should be able to be set and retrieved in any order.
• The member is static but returns a value that can be changed.
• The member returns an array. Properties that return arrays can be very misleading. Usually it is necessary to return a copy of the internal array so that the user cannot change internal state. This, coupled with the fact that a user can easily assume it is an indexed property, leads to inefficient code.