Based on the subsequent answers in the comments, the best solution for what you are looking for is the simplest: write code to copy the object yourself.
If your class is really simple, like a wrapper around a dictionary that stores key / value pairs for custom properties, you can use a dictionary (IDictionary) to copy values from one dictionary to another.
class MyWrapper { private Dictionary<string, object> properties = new Dictionary<string, object>(); public MyWrapper Clone() { MyWrapper output = new MyWrapper(); output.properties = new Dictionary<string, object>(properties); } }
Obviously, this is a simplified class that actually does nothing, but from what you have described, you should get what you need. No reflection, no "gotchas", just a simple copy of the values from one dictionary to another.
EDIT
I can’t talk about mono-portability, as I am a Windows-only developer, but as far as efficiency is concerned, the explicit solution in which you copy what you need will be an excellent winner over the reflection-based solution.
The concept of a true deep copy of any arbitrary type is not an easy (or even safe) achievement in an object-oriented language based on links. While simple classes would be trivial to copy, reference loops, classes without constructors without parameters, and immutable types that pose problems.
For example, consider this class:
public class Foo { public Foo Next { get; set; } }
This is a fairly simple implementation of a singly linked list. The naive deep copy algorithm started with the first instance of Foo , and then cloned it recursively, moving along the Next link chain, until it encountered a null value. However, by doing this, we will not only eat the memory, but also end up with objects that do not constitute an actual clone of the original:
Foo first = new Foo(); first.Next = new Foo(); first.Next.Next = first;
This is a perfectly legitimate (and even reasonable) thing, but now we have a circular reference cycle that will blow up our naive cloning algorithm. So now we have to implement the object cache.
Dictionary<object, object> clonedObjects;
Now, in the cloning algorithm, when assigning values to properties or fields, we check the cache to see if the link we are going to duplicate has been cloned. If so, we use this value instead of cloning a new one. This will give us a completely new graphic object that represents our original object and is also a complete clone. Great, right?
Now, what about parameterless constructors? This is not even solvable in a completely general sense. If I create this class:
public class Bar { public Bar(string gotcha) { } }
There is no way to clone this class in a naive sense; since you don’t have a way to find out how to call the constructor (you can get ConstructorInfo reflexively, but the semantics of what it is called will be completely unknown. The best thing you could do is to store metadata (via a custom class attribute) about which constructor should call and how to call it (a list of fields in the order in which they should be passed, for example), but this requires prior knowledge of the cloning mechanism, and also implies that the arguments for the constructor are fields on the original object which is optional.
Now we throw one more catch into the mix: immutable reference types. It can also lead to unexpected behavior. Immutable reference types are reference types whose (externally visible) value cannot change; in most cases, these classes are intended to express the semantics of meaning. They also often lack parameterless constructors (and may not even have publicly accessible constructors at all), causing them to suffer from our previous annoyance, but they can also use a factory-based method so that they can guarantee that reference equality also means equality of values and vice versa (this last condition is less common, but if we are talking about an algorithm that is a completely naive cloning mechanism, then we should cover it). This again means another custom attribute, indicating that the cloning mechanism should simply copy the link, rather than clone the actual object.
So, in short, a completely naive deep copy mechanism is simply not possible when working with arbitrary types. Types must be designed with the cloning mechanism in mind, and they may have to make concessions or decorate themselves in a certain way to work with it. This, combined with the relatively infrequent requirement, is probably why there is no deep copy mechanism at the structure level now, and why you should consider a more explicit copy mechanism when you know what to copy (and what doesn't matter) so you can be sure that you get what you want.