Welcome to CSharpTest.Net

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
 

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:

1. Option #1 - just leave it alone. The downfall here is that specific types of exceptions cannot be caught easily in calling code. In some instances this can be a very big problem.
2. Option #2 - re-throwing the InnerExcpetion property. This at least preserves the type of the exception and thus code above you in the call stack will correctly catch and handle exceptions. The problem here is that the stack information previously held in that exception is lost.
3. Option #3 - Avoiding the problem. If you know the types of the calling parameters you can construct a delegate from the MethodInfo. By calling the delegate (not using DynamicInvoke) the issue is avoided. Again this only works if you have compile-time knowledge of the parameters.
    
   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();
   }
   

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 before, sometimes things I call even use it; however, a larger part of the time I still have to overload the object’s GetHashCode/Equals.

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.

A good friend of mine who is the definition of a ‘Security Expert’ replied to my recent post regarding the use of current encryption technologies. He had this to say about my assertion that PKI cannot prove my identity:

PKI-based authentication can prove who you are, to the extent it can prove that the name in the certificate corresponds to the entity wielding the private key.

Since he seems by this to have missed my original statement I wanted to clarify why I don’t believe PKI technology can be used for personal identity. The problem isn’t the technology, certainly if I am only one with the private key then I can prove who I am. My argument is that you cannot secure the private key.

Oh sure, you could take that private key and ACL/encrypt it down to my user account. Even better you could put it on a thumb drive bio-metrically encrypted for only my access. This is still insufficient security. Programs running on machines that I use when accessing that data can get to that data. Since you cannot secure the platforms we use, you cannot secure data stored or accessed by them. Not that the technology is wholly unusable, for some things it would be entirely sufficient; however, I sure wouldn’t want my private-key to be the only thing needed to access my online banking.

Let’s say we went down this road and everyone had a private key. That provides one attack everyone is vulnerable to. It would be a matter of hours before people started finding ways around whatever security was in place. Wherever you have more potential victims and higher rewards the criminals will attack. Why do you think MS-Windows has been attacked the most?

The hidden beauty behind the mess of online credentials is that everyone does it differently. This forces an attacker to pick something specific to target, like PayPal, or BoA. The attack, if successful, only works there. This is a good thing. Putting all our eggs in one security basket is just a bad idea… Kinda like using the same username and password on every website you visit.

An excerpt of a recent slashdot post:

“… I wanted to ask the Slashdot community, what do you think the hold up is (regarding use of encryption)? Are the existing protocols somehow not good enough? Are the protocols fine, but not supported well enough in software? Is it too complicated to manage the various encryption protocols and keys? Is it ignorance or apathy on the part of the IT community, and that we’ve failed to demand it from our vendors?”

I think I’d go with a few core issues on this one…

First, a large part of the development community is is ignorant of the encryption technologies and how to make them work.

Second, a larger problem is the greed of the existing trusted root authorities. Most individuals are not willing to expend the ridiculous amount of money required just to assert their identity. IMHO it’s an evil exploitation.

Third, and most important. The meat of the problem is ‘identity’. How do I prove who I am? PKI cannot solve this. Why? Because I use several machines to interact with the web not one. If any of these machines, some of which I don’t control, are compromised then some other party can act on my behalf. No machine is secure enough for me to trust it with that kind of control over my online identity.

Thus we are where we are, PKI is expensive and not well understood by most developers. Further, even if this were overcome it would not server as proof of who I am. To truly address the issue a completely new technology/approach is required. I rather doubt we will see a solution in our lifetime.

Changed hosting environments, hopefully this will be less painful to all :)

My last post reguarding “Deadlocks and other issues with Invoke / BeginInvoke” was something of a rant on the subject of WinForms and multi-threading. I thought I’d post on the useage of the solution that was presented originally on the stackoverflow article. The following defines the interface portion of the class:

    public class EventHandlerForControl<TEventArgs> where TEventArgs : EventArgs
    {
        public EventHandlerForControl(Control control, EventHandler<TEventArgs> handler);
        public EventHandlerForControl(Control control, Delegate handler);

        public void EventHandler(object sender, TEventArgs args);
    }

Using this class is incredibly easy. Let’s assume our form is creating a ‘worker’ object and wants to know when some value has changes via an event. We simply need to modify the subscription to the event.

The wrong way:

    class MyForm : Form
    {
        public MyForm()
        {
            _worker = new Worker();
            _worker.OnUpdate += this.Worker_OnUpdate;
        }
        private void Worker_OnUpdate(object sender, EventArgs e)
        {
            if (this.InvokeRequired)
                this.Invoke(new EventHandler(Worker_OnUpdate), sender, e);
            else
                ;//whatever
        }
    }

Now we just do the following with the help of EventHandlerForControl:

The right way:

    class MyForm : Form
    {
        public MyForm()
        {
            _worker = new Worker();
            _worker.OnUpdate += new EventHandlerForControl<eventargs>(this, this.Worker_OnUpdate).EventHandler;
        }
        private void Worker_OnUpdate(object sender, EventArgs e)
        {
            ;//whatever
        }
    }

Now whenever the event OnUpdate is fired it is automatically marshaled to the correct thread no special handling is needed. You can also be certain that either the call is successfully made or an exception will be thrown to the caller.

EventHandlerForActiveControl<T> - Use this class if you do not want an exception thrown when when the target control is not available. The method will not be called when the control is not active.

ForcedEventHandlerForControl<T> - Use this class if you do not want an exception thrown when when the target control is not available and you still want the method to execute.

All of these are defined here if you just want the source code.

Just ran into this post over on devlicio.us and thought it worth a shout-out. Much like the CommandInterpreter I recently added to the library, it allows you to remove all the parsing of arguments from your code and provides command-line help. Here is to hoping that a full-blown version eventually finds it’s way into the core runtime. Until then I’ve been very pleased so far with the version I built.

The answer is simple… only when the profiler tells you to.

Optimizations often make code less reliable and often constrain implementations making them less flexible. Good software performance is not created by making lots of micro optimizations throughout your code. A good design from the architectural point of view is the critical key to success for performance.

Why would I say this? Why are optimizations bad? Allow me to demonstrate a few types of optimizations that should only be done after careful consideration and profiling:

1. Lazy Loading: I hate the term as it’s not a lazy approach. Go with the lazy approach and don’t do this until it’s a problem. Writing a property to have strange side-effects on an object is just a bad idea to begin with. If the performance of loading a collection of data is so bad that you must avoid it, then use a method that does not cache the result. Make it clear to callers that the data is not cached but loading with each call. For instance if you want a collection of Students from a Teacher object call the method “FetchStudents()” rather than “GetStudents()”.
2. Caching: WTF, so many people think this is some kind of great idea. Caching is evil it over complicates code and causes strange side-effects all over your code. Just to be clear I’m not talking about caching of computational results in a data store, I’m talking about caching results of data store requests. Don’t ever do it… ever. A noteworthy exception to the rule is dealing with read-only or write-once data.
3. Micro Optimizations: This is hard to define but let’s review a few examples on stack overflow. See “Array more efficient than dictionary“, “Are doubles faster than floats“, or “Is if-else faster than switch“. These kinds of optimizations are just silly. Write readable, maintainable, testable code first, then analyse the code with a profile if you have a problem. I loved John Skeet’s response to the first of these questions entitled “Just how spiky is your traffic“.

Enough about what not to do… what should you do? Always be aware of cost of the algorithm you are choosing. Choosing the right data structure and/or algorithm at the onset of coding can result in highly predictable and scalable software. Inversely failing to do so can cause non-linear performance as the volume of data increases eventually yielding unusable software. We’ve all seen this happen in a database application with a non-indexed query. This can happen in your own C# code too so don’t be an idiot but don’t spend all your time focused on the fastest approach. Look instead for a predictable linear-growth solution that fits your needs.

Remember there are three competing interests in any piece of code. Flexibility, Reliability, and Performance. Any two of these can be achieved at a reasonable level at the sacrifice of the other, or you can excel at any one at the cost of the other two. The choice is yours to make and will change from task-to-task and project-to-project. I call this the ‘Software Quality Triangle’ because of it’s similarity to the age-old project manager’s triangle (Cost, Time, or Features). By graphically representing each concept as a point of an equilateral triangle and positioning the axis of rotation at it center you can gain perspective of what you will sacrifice over what you will gain. For instance, by rotating the triangle so that Performance is pointing straight up (it’s highest level) the other two points (Flexibility and Reliability) will drop.

This ‘helpful’ (using this term loosely) post is for those you considering adding multi-threaded code to your application.  The intended audience is developers with less than mastery-level (10+ years) multi-threading experience.

The first question your up against is:

Do I need multi-threading in my application?

The answer is an emphatic NO you don’t.  If you accept this answer you can quit reading now; otherwise I have a different question for you:

Would you be willing to voluntarily walk across across 100 yards of molten lava, bare foot, carrying a 250lb backpack, uphill, with a blind fold on, all the while ignoring the perfectly good bridge over the lava you simply ignored because it was too easy?

Seriously though, avoid at any cost as much as you can adding multi-threading code.

Common ramifications of threading

• Most applications that employ threading find a great majority of their bugs in the threading code.
• Almost always the difficult/impossible to reproduce issues stem from broken threading.
• More often that not, the application actually performs worse once you start multi-threading.
• Most of the time threading wasn’t truly *required* in the first place.

If you still think multi-threading isn’t that hard read this article on a simple thing like initializing a static variable in a thread-safe manner:  http://www.yoda.arachsys.com/csharp/singleton.html

So you still want to do multi-threading?

Well, I tried and failed.  Now you need to go learn EXACTLY what the following are used for and when/why you would use them (and generally in this order):

1. Thread
2. ThreadPool
3. ManualResetEvent
4. AutoResetEvent
5. EventWaitHandle
6. WaitHandle
7. Monitor
8. Mutex
9. Semaphore
10. Interlocked
11. BackgroundWorker
12. AsyncOperation
13. lock Statement
14. volatile
15. ThreadStaticAttribute
16. Thread.MemoryBarrier
17. Thread.VolatileRead
18. Thread.VolatileWrite

		private volatile object _data;
		public object Data
		{
			get
			{
				if (_data != null) return _data;
				lock (this)
				{
					if (_data == null)
						_data = new object();
				}
				return _data;
			}
		}

		public object Data
		{
			get { return _data ?? _data = new object(); }
		}

I’ve seen many a question on stackoverflow and other places about running a process and capturing it’s output. Using the System.Diagnostics.Process correctly is not easy and most often it’s done wrong.

Some common mistakes with System.Diagnostics.Process:

1. Not capturing both output streams (error & output)
2. Not redirecting input can cause applications to hang
3. Not closing redirected input can cause applications to hang
4. Using OutputDataReceived/ErrorDataReceived without waiting for null
5. Not checking for null in OutputDataReceived/ErrorDataReceived handlers
6. Forgetting to set EnableRaisingEvents = true; when using the Exited event
7. Forgetting ErrorDialog, CreateNoWindow, or UseShellExecute settings
8. Incorrect handling of StandardOutput or StandardError stream readers

So with this said, here are some basic guidelines:

1. Use the OutputDataReceived/ErrorDataRecieved events NOT the StandardOutput or StandardError. This will save you a lot of headache and needless thread management.
2. Always capture all output AND input, if you don’t plan to provide input, close the stream immediately.
3. Your process isn’t done until it exited AND you have read all the data. OutputDataReceived CAN AND WILL be fired after a call to WaitForExit() returns. You will need wait handles for each output stream and set the wait handle once your receive (null) data.

To see how this done correctly review CSharpTest.Net.Processes. ProcessRunner.

Read more on Using the ProcessRunner class.