June 2006 - Posts
Yesterday I
blogged about some if the weird runtime errors we had been experiencing. Well some colaberatiosn between several MVP's (great crowd btw) led to a partial solution. By adding:
<Assembly: Debuggable(True, True)>
to the project will efectively turn off all JIT optimizations for the whole assembly. Not the best of solutions because it sure hurts perormance :-( and even then not a compete one because some of the issues like an invalid cast to System.__Canon still remains. But atleast we have the app running in a more or less stable manner.
Still this experience sucks and makes me a bit wary of .Net 2.0.
There is an old compiler writer’s motto that says: Making a wrong program worse is no sin. There is another motto that says: A bug free program doesn’t exist.
Well it seems the Microsoft .NET runtime JIT team has combined the two motto’s allowing perfectly good code to go wrong :-( And I have recently been bitten multiple times by this.
So what happens? Well I have code that runs perfectly well from within Visual Studio 2005, both debug and release build that is. Now I run the release build as a standalone application on the same machine and it starts failing in strange ways. The sort of error you might get is invalid casts, I had one that claimed it couldn’t cast to System.__Canon. Now I have no idea what System.__Canon is used for but I am very sure I don’t use it in my code as it is an internal class in mscorelib.
So how do I work around these issues?
Well so far the only way I have found is to disable the JIT inlining for specific functions, usually a little higher up in the call stack, normally found by trial and error. Use the MethodImpl(MethodImplOptions.NoInlining) attribute on the function to disable the JIT.
So where does this leave me? Well with a certain distrust of the .NET runtime. Clearly I can’t trust the results after testing either in Visual Studio itself or a debug build. Now I am a fan of creating unit tests but being forced to run these outside the normal development environment and only on release builds is a major PITA. Not only does this waste a lot of time the very fact that it is needed makes me a little wary of releasing code to customers. After all I never know if some obscure JIT bug like this is going to be machine dependent and only bite me on the customer’s machine.
Doing any SharePoint work? Well there is a useful free SharePoint 2007 book out there.
If, like me, you are a fan of DevExpress, ok actually Mark Miller's, CodeRush and Refactor products you will be happy to know that version 2.0 has been released. If you have never used them before I suggest you take a good look at them. They me save a bundle of time when doing work and time is one thing I am always short on :-(
The following is a piece of code I recently ran into:
IAsyncResult asyncResult = m_Queue.BeginPeek();
while (!asyncResult.IsCompleted && m_Running)
Thread.Sleep(10);
if (m_Running)
{
Message message = m_Queue.EndPeek(asyncResult);
ProcessMessage(message);
}
Now this is already running in a background thread, not that it makes a lot of difference though. But calling an async begin function, then sleeping until it is finished and retrieving the result makes no sense whosoever. You might as well just call the regular Peek() and be done with it.
So the rational behind writing it this way? Well Peek raises and exception if there is no message in the queue and exceptions are expensive so the developer wanted to avoid them at all cost, even in a background thread. Not exactly my idea of clean and readable code. The guilty know who they are :-(
In de avond van 28 juni aanstaande organiseert de VBcentral gebruikersgroep een VBevent. André Obelink presenteert een sessie over de nieuwe taalelementen in Visual Basic 2005. Hierna geeft Thomas Huijer een presentatie over software testen met Visual Studio 2005.