The first one is a public variable (a field) of type string, the second one is a property.
Here you see 5 reasons why use properties over fields (
http://stackoverflow.com/questions/4142867/what-is-difference-between-property-and-variable-in-c-sharp[
^]):
1 - Fields can not 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