I hope that digging through these pages will provide you with some useful information and possibly some useful tools to help you further your development endeavours. General announcements are below and you can find a complete list of postings under the Blog link above. Please feel free to contact me by posting here or sending an email to my first name, Roger, at this domain.
Thanks for stopping by,
– Roger
Changes in this version:
This plugin should now be functional on 64-bit installations of TortoiseSVN, use the following installation:
http://code.google.com/p/csharptest-net/downloads/detail?name=SvnPluginInstall-x64.msi
Let me know if you have any difficulties.
Recently I was killing time on stackoverflow and found this question:
What is the best comment in source code you have ever encountered?
There are a lot of great quotes in there. If you haven’t seen it already it worth a read when you want to kill some time. I’d also add my own to the list:
// The DM warns the following encounter is EL25 and should only be attempted
// by Epic level parties.
As promised in the previous post “How to implement a generic Shallow-Clone for an object in C#” this will demonstrate deep-cloning objects that don’t explicitly support the behavior.
Before I continue I will again state that I don’t recommend this approach. It will be many times slower than a properly implemented Clone() and can cause rather strange side-effects. For instance, deep-cloning a tree of objects that hold reference to a singleton service class would result in cloning that singleton. This problem simply stems from the fact that no generic code can have enough knowledge about the internal structure of classes to be able to accurately guess when and when not to clone a member reference. Thus if you going to code the logic of which members to clone or not, it’s best done in the objects themselves and is the primary reason I say a generic deep clone is a bad idea. Even if you don’t currently have a reference to a singleton now, what happens when someone adds one to the object graph? How will your application behave?
So with this established as a bad idea it is with great trepidation that I demonstrate how to achieve this. To start with let’s demonstrate usage in the Library:
using CSharpTest.Net.Cloning;
//Uses serialization API if available or member-wise if non-serializable
using (ObjectCloner cloner = new SerializerClone())
fooCopy = cloner.Clone(foo);
// 3.5 can use extension method instead of the code above:
fooCopy = foo.DeepClone();
//To ignore serialization routines, use the following:
using (ObjectCloner cloner = new MemberwiseClone())
fooCopy = cloner.Clone(foo);
Implementation details, there are not a lot to share, you can see the source easily enough at:
http://code.google.com/p/csharptest-net/source/browse/#svn/trunk/src/Library/Cloning
There are a few things worth pointing out. The ObjectCloner provides a base-class that handles the object graph and a few well-known types (delegates, arrays, primitives, etc). Derived from this is the MemberwiseClone class which provides a basic ‘memory copy’ type of copy operation. Again deriving from this is the SerializerClone which implements a pseudo serialization routine by attempting to mimic the .Net serializer’s default implementation. This results in three possible types of copy operations:
1. If ISerializable is implemented it will be used, allowing customization of the copy.
2. If [Serializable] decoration is present the FormatterServices.GetSerializableMembers is used to allow respecting the [NonSerialized] attribute.
3. Lastly if the object doesn’t support serialization a straight member-by-member copy is made.
This continues throughout the object graph until all object members have been copied into the new tree. Finally if appropriate calls to IDeserializationCallback will be made just prior to the top-level instance being returned.
One thing of note is that the object graph is made public to allow preventing some instances from being copied. For instance if you want to copy foo’s complete object graph except for any instances of ‘bar’ then you would do this:
using CSharpTest.Net.Cloning;
using (ObjectCloner cloner = new SerializerClone())
{
// maps instances of bar to itself:
cloner.Graph.Add(bar, bar);
fooCopy = cloner.Clone(foo);
}
Changes in this version:
This implementation makes heavy use of the FormatterServices object used by serialization:
http://msdn.microsoft.com/en-us/library/system.runtime.serialization.formatterservices_members.aspx
It provides several helpful methods in this case that are aware of custom serialization options like [NonSerialized]. In the case of an object not being marked [Serializable] you have to create field list manually. Here is an example shallow object clone:
using System.Runtime.Serialization;
using System.Reflection;
static class Clonable
{
public static T Clone<T>(this T instance)
{
object copy;
Type type = instance.GetType();
if (instance is ICloneable)
return (T)((ICloneable)instance).Clone();
List<MemberInfo> fields = new List<MemberInfo>();
if (type.GetCustomAttributes(typeof(SerializableAttribute), false).Length == 0)
{
Type t = type;
while (t != typeof(Object))
{
fields.AddRange(t.GetFields(BindingFlags.Public | BindingFlags.NonPublic | BindingFlags.Instance | BindingFlags.DeclaredOnly));
t = t.BaseType;
}
}
else
fields.AddRange(FormatterServices.GetSerializableMembers(instance.GetType()));
copy = FormatterServices.GetUninitializedObject(instance.GetType());
object[] values = FormatterServices.GetObjectData(instance, fields.ToArray());
FormatterServices.PopulateObjectMembers(copy, fields.ToArray(), values);
return (T)copy;
}
}
As with anything, use this carefully. This method run against some objects will cause native handles to be copied and can then lead to application crashes in unmanaged code.
If you need a deep clone things get a lot more complicated. I don’t recommend it; rather you should insist that objects are decorated with [Serialiable] and simply use serialization to copy the object. That being said, I will post a working deep-clone as a follow up to this post.
Sorry to misappropriate my blog for a moment but I had to post this.
Hi, my name is Roger and I’ve been video game free for 8 years. In that time I’ve fallen off the wagon a few times; however, they were brief episodes. As a recovering gameaholic this video really strikes home for me. The message to gamers is spot-on IMO, I just wish those still addicted could truly ‘hear’ what he is saying. See for yourself:
http://www.youtube.com/watch?v=YKBRG_QgEAM
Aside from the message alone, I also want to complement the author on the quality of the video. He is obviously talented at more than just button mashing.
Sometimes a picture is worth a thousand words…
I simply ‘cringe’ every time I hear a developer utter the words “I’m going to do this RIGHT!”. Why do we use the words “Right way” and “Wrong way” when describing things? The fact is that there is a lot more than just one “Wrong way” to do something, trust me on this. Further there are a vast multitude of “Right ways” to do anything in software. The simple idea that you know and grasp what is the “Perfect” way of doing something is absurd. Take your pick of a software demi-god and ask them if they ever strove to write something “Right” only to figure out by the end it wasn’t the “Right way”.
So here is a quote of mine that sums it up:
The closer you get to your perfect solution the more your idea of the perfect solution changes and thus the perfect solution cannot be obtained.
We need to recognize that the world of software is not black and white. It is instead an infinite number of shades between the two. The problem we should concern ourselves with is not how to do things “Right”, but rather ask ourselves what is “Good Enough”.
We first recognize the term “Good Enough” to be something that cannot be defined in a concrete way. The term refers to one of those gray areas between black and white and has no consistent definition. As such, for every project, for every class or method, for every line of code we have to redefine “Good Enough”. There are a number of supporting principals of software engineering like YAGNI, SOLID, TDD, etc that aid us to achieve this elusive definition.
For those that want to see a concrete example, this is “Good Enough”:
public static void Main(string[] args)
{
DoSomething(args[0], args[1], int.Parse(args[2]));
}
… good enough that is for an internal tool that will only ever be called from a single build script. I’ve done this several times on small utilities and I’d argue in those cases there is nothing wrong with it. Yet if you needed to do the same thing for a customer facing utility the same routine might need several classes and a hundred or so lines of code behind it.
In summary, next time you start writing code ask yourself “where on the exponential graph of cost vs. quality do I want to land?”. If I’m writing a routine to keep a heart-implant pumping blood inside someone’s body I’m probably going to want to put some effort into it. However, if I’m writing an argument parser for a command-line app used exclusively by our build then the opposite extreme would apply.
How to throw the InnerException of a TargetInvocationException without loosing stack details?
I’ve been plagued by this problem for some time. There are a few common solutions to this:
Most of the time one of the above has been an acceptable solution; However, recently I ran into the case where none of the above would work. The code has been around a while using option #2 above since the arguments are unknown. Changing the behavior to not throw the original exception type was out since it could break existing client code. The problem that was killing me was the loss of the stack when debugging and monitoring log information. The loss of this information was making spend hours trying to figure out where the thing failed.
So I needed to use MethodInfo.Invoke(), needed the stack and the original excpetion type to be persevered… but how?
Well the first thing I came up with is the following routine which gets down-and-ugly with the Exception class. The catch-block finds the inner-most TargetInvocationException and extracts the InnerException. Then using the Serialization helpers it basically copies the fields of the object to an array. Now we re-throw the exception to set it as the ‘current’ exception when we next call throw without an argument. And finally after we’ve lost our stack we stuff it back in by calling the Serialization helper again to push all the fields back into the exception before calling throw one last time.
Bad Code, do not use
[System.Diagnostics.DebuggerNonUserCode]
[System.Diagnostics.DebuggerStepThrough]
private static void Invoke(MethodInfo method, Object target, params Object[] invokeArgs)
{
try
{
method.Invoke(target, invokeArgs);
}
catch (TargetInvocationException te)
{
if (te.InnerException == null)
throw;
Exception innerException = te.InnerException;
MemberInfo[] fields = FormatterServices.GetSerializableMembers(innerException.GetType());
object[] values = FormatterServices.GetObjectData(innerException, fields);
try { throw innerException; }
catch(Exception exception)
{
FormatterServices.PopulateObjectMembers(exception, fields, values);
throw;
}
}
}
This all worked well… However, I started to wonder about how this might effect some types of exceptions. I started thinking maybe I should serialize & deserialize the object first. I started thinking I was making this too complicated just to preserve a stack trace.
I finally just started reading the exception code and found they have exactly what I want already baked in… just not exposed. The method only preserves the stack, nothing else… perfect. So why not solve a reflection problem with reflection:
[System.Diagnostics.DebuggerNonUserCode]
[System.Diagnostics.DebuggerStepThrough]
private static void Invoke(MethodInfo method, Object target, params Object[] invokeArgs)
{
try
{
method.Invoke(target, invokeArgs);
}
catch (TargetInvocationException te)
{
if (te.InnerException == null)
throw;
Exception innerException = te.InnerException;
ThreadStart savestack = Delegate.CreateDelegate(typeof(ThreadStart), innerException, "InternalPreserveStackTrace", false, false) as ThreadStart;
if(savestack != null) savestack();
throw innerException;// -- now we can re-throw without trashing the stack
}
}
The person that made this ‘internal’ should be flogged. How very easy of a solution that is and perfectly safe for all types of exceptions. It appears it will even work with remoting, serialization, cross app domains, etc.
My first request for .Net 5.0:
partial class Exception {
public void PreserveStackTrace();
}
Updated: Apparently this isn’t a new hack, I should have done some google’ing ;)
There are three virtual methods that IMHO should have never been added to System.Object…
• ToString()
• GetHashCode()
• Equals()
All of these could have been implemented as an interface. Had they done so I think we’d be much better off. So why are these a problem?
First let’s focus on ToString():
1. If ToString() is expected to be implemented by someone using ToString() and displaying the results you have an implicit contract that the compiler cannot enforce. Your code might assume that ToString() is overloaded, but there is no way to force that to be the case. Had this been an interface, say IDisplayString, your client code would be able to ensure that an object implement this.
2. Most argue the benefit of overloading ToString() is for the debugger. You should NOT be doing this, instead you should start using [System.Diagnostics.DebuggerDisplayAttribute].
3. As for needing this implementation for converting objects to strings via String.Format(), and/or Console.WriteLine, they could have deferred to the System.Convert.ToString(object) and checked for something like ‘IDisplayString’, failing over to the type’s name if not implemented.
4. Exactly what ToString() returns or should return seems to be a matter of debate and is the worst of all it’s problems. Is this a display string? If so, for what culture? Is this a serialization string? Is it just for debugging? There doesn’t seem to be any correct answer.
And don’t even get me started on GetHashCode/Equals.
1. Overloading .Equals has nothing to do with expressing equality in your code (value1 == value2) unless you remember to call it directly. Stupid!
2. There are numerous ways in which to compare two objects. Reference comparison is one, or perhaps by an object’s identity field, or even a name field? What I love most is that the reference comparison is difficult to produce on an object that overloads these. Does anyone know how to get the ‘hash’ of an object’s reference (memory location)? BTW you can, it’s not in an obvious place like Object.GetHash(object), it’s RuntimeHelpers.GetHashCode(object).
3. Casting — why lord, why? Why must you make me cast the object I’m comparing myself to. And what do I do with null or some other object type? Is there some standard I’ve never heard of that defines the appropriate action? Certainly neither equality or inequality are the correct response?
4. What comparison will be used? I’ve implemented IEquatable
5. Much like ToString() there isn’t a way to tell if an object actually implements this behavior. If it does, did I want them to is an entirely different story. They could be breaking my code by implementing these without either of us knowing I was depending upon reference comparison.
So I say enough already, can we please just deprecate these already? I’d even be willing to find and fix all the places I’ve been unwillingly forced to use these damn things.
