The main purpose of RealCodersCoding is to post about problems we, the authors, have overcome in our daily coding adventures. Sometimes, the problems we are faced with are complex and require some interesting coding yoga to to work out. Other times the solutions are drop-dead simple, but we refuse to recognize them. Here's a little post about how I wasted an entire freakin' day to one of the latter.
Would you like to know more?
by Bogdan Varlamov (a.k.a. Phantom Stranger)
One of the great things about .NET 3.5 is that it is fully inter-operable with .NET 2.0. You just have to reference the right assemblies and you can use WPF and Windows Forms from the same application! This is great for slowly migrating a .NET 2.0 application over to .NET 3.5; all you have to do is add the new functionality while keeping your old .NET 2.0 logic. Once you are ready, you can slowly migrate your old code over into .NET 3.5 as needed.
Well...at least it's all that easy in theory; there's just one pesky little hiccup--a System.ExecutionEngineException...
Would you like to know more?
by Bogdan Varlamov (a.k.a. Phantom Stranger)
I recently ran into an issue with an application that was not detecting a physical network problem and was consequently losing data while attempting to write it to the socket.
I know what you are thinking. Sounds like poor programming; surely the .NET Socket class has a clean and Object Oriented way of handling network failures.
That is what I thought at first. The .NET Framework is filled with tons of goodies--namespaces with classes that make coding life easier. I am usually fairly satisfied with what is available in .NET (especially in .NET 3.5), but when it comes to the System.Net.Sockets namespace, there is just more to be desired.
Would you like to know more?
by Bogdan Varlamov (a.k.a. Phantom Stranger)
Do you have an application that starts misbehaving randomly? You aren't quite sure what is going on, but it seems like for some reason your Timer just stops firing it's event handler--and once it stops it never starts back up.
This drove me nuts! But, it is definitely a problem in the Windows Server 2003 SP1. This bug is particularly devious since even if your application uses extensive logging it maybe be nearly impossible to find proof of a timer not firing in your logs.
Short of implementing a Homer Simpson type of "everything is okay alarm" is there anything you can do to determine whether or not your application might be suffering from dying timers?
Would you like to know more?
Share / Bookmark
