+3  A: 

1 and 2 conflict, basically.

Either your type is immutable, in which case you can return a reference to the same instance every time... or it's mutable, in which case you have to return a reference to a new object each time.

The reason string.Empty is fine is precisely because string is immutable.

Does your type have to be mutable?

EDIT: Based on your comment, it sounds like the properties shouldn't have setters at all. Instead, the values should be passed into the constructor, and stored in readonly fields.

At that point your type is immutable, so you can expose either a public field or property which always returns the same value, i.e.

private static readonly MyType empty = new MyType("", ""); // Or whatever
public static MyType Empty { get { return empty; } }

or

public static readonly MyType Empty = new MyType("", "");

You don't need to worry about anyone setting any properties, because you haven't got any setters...

Jon Skeet
I once the properties are set, they should never change. So the answer is no, right?
CS
Editing answer to reflect comment...
Jon Skeet
This is true, that is how I initially set the properties, via the constructor. Unfortunately I forgot to mention that the type will be serialized with XmlSerializer. To my knowledge, that requires public get/setters for all serialized properties. However, if I implement IXmlSerializable (this is a small class destined not to change), I do not require public setters. Correct? If this class were to change, I not only have to change/add fields, but also the strings in the IXmlSerializable implementations?
CS
Ah. I'm afraid I'm far from an expert in XML serialization, but that sounds like it might work...
Jon Skeet
Wouldn't that be a breaking change if Empty's value was changed between implementations? Usually serializing the empty constant would not be required.
Will Eddins
@Guard: Potentially, yes. There are all kinds of difficult situations to consider when it comes to versioning and serialization, regardless of technology :)
Jon Skeet
The special gotcha here is that an object that references the static Empty and is then serialized and deserialized now references a copy of the static, so a reference comparison will fail. This sometimes bites people who serialize DBNull and test for it by reference instead of class.
Steven Sudit