(No) Love at First Sight
Since I joined my current company, DILE author, who has already joined the company earlier, has been trying to recruit me as a DILE user, if not a fan. It is indeed difficult to teach old dog new tricks! For the good part of 2009, I kept ignoring DILE while troubleshooting issues that can be easily traced using DILE. That poor author even has given me a quick tutorial about DILE in one of our knowledge sharing session, but I was still not moved. Only when faced with problems with no viable troubleshooting approach DILE came to my mind. Pretty stubborn, huh? 
What is DILE?
From its SourceForge homepage:
Dotnet IL Editor (DILE) is an editor program which helps modifying .NET assemblies. It is intended to be able to disassemble .NET assemblies, modify the IL code, recompile it and run inside a debugger.
As of the current release, the editor part of DILE has not been implemented yet. Anyway, IMHO that is not an important part. DILE is most useful used as a debugging tool. You may ask what we need DILE for. All this time we have been debugging without DILE and yet we still live.
These are the conditions where DILE makes (programmer) live less miserable:
1. The application-in-trouble was installed on a server environment, not development environment.
2. The application is using 3rd party libraries. No debug symbol, no source codes, or even worse no documentation for the external libraries.
3. Application has very little logging, if any.
Let’s discuss each point in more details.
DILE does not need to be installed, just copy and run it, so it will not “contaminate” our servers. It has small footprints, less than 400 KB. Better still, it only requires .Net framework to run. So unlike your (most likely) past experience, you don’t need Visual Studio for debugging. With DILE you can debug in a deeper level than using VS.
For point #2, this is where DILE really shines in my cases. I have been dealing a lot with in-house products/libraries with almost no documentation. So whenever there is an error when calling an external assembly, I will always be in doubt. Is the error because of my codes, or is it the external assembly’s fault. Not uncommonly happened, the assembly referred at run-time was the wrong one. With DILE we know exactly which assemblies are loaded and we can see during run-time the execution path. Without DILE, it is almost impossible to know what is going on during run-time at the level of details sufficient for troubleshooting.
The basic need of knowing what is going on during time, to certain extent, can be fulfilled using application logs. There is an issue with logging though: log will not be as detailed as the codes. More logging means more noise to the source codes, obscuring the actual logic. Log is also cumbersome for tracing execution path. Imagine. for example, you will need to put a log in every branching of codes as well as showing the variable values relevant to that branching. With DILE, you can see the actual codes running, current variable value, etc, even those that you are not aware of before, such as optimized codes.
Using DILE
So how do we use DILE? Let’s wait until I write Part 2. Stay tuned
BTW, for the impatient folks, check this out.
