Should a string property default be String.Empty or NULL?

This question seems trivial and it perhaps should belong to the programming practises section, but I still don't understand it thoroughly...

Suppose I have the following property:

public string SomeProperty {
 get {
 object o = ViewState["SomeProperty"];
 return (o == null ? <some_default_value> : (string)o);
 }
 set {
 ViewState["SomeProperty"] = value;
 }
}

From what I know, if it were an Int or other types property, I would have no choice and give it a default value of the same type as the property's type. But in this case (in C#) a string property I am able to choose between String.Empty or null. They are both legal.

Should I always default it to string.Empty or null?

If I default it to string.Empty, my concern is that if there are other access to the ViewState["SomeProperty"] other than through SomeProperty, I might get value null because ViewState["SomeProperty"] if uninitialized returns null.

If I default it to null, it might work if I am being completely consistent in everything (all uninititialized string properties SomeProperty2, SomeProperty3, etc. in my control will return null). But am I introducing a non-type safe convention by assigning a string property a not-really-string-type value - null?In your example, if that object in viewstate does not exist, it will return null. I think you would be safe to use it this way.
No... in my example, if I access SomeProperty before I set it to something, it won't necessarily return null but instead will return <some_default_value>, which is what I am trying to put in, and also the point of my question - should it be String.Empty, or should it be null? Which one is better, why, and why the other choice is not as good?

Thanks for your response mhawley.
It depends greatly on the context. If you return string.Empty, your property will always be a valid string and can be used directly without having to check for null. It can make your user's life easier.
On the other hand, if null has a special meaning that is different from string.Empty, you have to return null as in "not set, but not empty".
Does this help?
Ok. It sure depends on the context. If null means something different than string.Empty, sure I need to make it other than string.Empty, which null would fit in perfectly.

The reason I ask this question is because in a lot of custom control I have seen, properties (especially string ones) are piled up for 10 pages before I see the constructor, and these properties which expose ViewState items are all being used/set by the control users to do something. For example, if I have a control that exposes a string "SearchExpression", and the control user is supposed to use this to set the databound control's datasource before passing in the 'rowfiltered' datasource to databind(), it makes me think what is a good or standard value to return "SearchExpression" from the control, whether null or string.Empty.

I guess afterall this is a dumb question...