The Pain and Anguish of DTS Script Debugging

I recently had the misfortune of having to create a DTS package (in Visual Basic, to add insult to injury), and had a helluva time trying to find out what was happening in the code as it was running. The environment is a 2003 Server that I have to remote-in to, and then run the appropriate dev tool. The problems were many:

• Setting breakpoints - when I tried to set a breakpoint and then run the task, I would get a dialog box saying that the debugger had encountered a problem and was shutting down. It is suspected that the fact that we have to remote-in is the culprit, but we don't have the ability to find out for sure, so setting breakpoints was not feasible.
• Displaying message boxes - This was suggested by the guy that had previously been the maintainer of the scripts in question. While useful, it interrupted the program so many times that it became unwieldy. Fail.
• Using Debug.WriteLine - this just plain doesn't work. Nothing is displayed in the output window as a result of Debug.WriteLine. Fail again.

At this point, I discovered the Progress tab in the IDE.

• Using Console.WriteLine - this just plain doesn't work. Nothing is displayed in the Progress tab as a result of using Console.WriteLine. Fail again.

Finally, I found out about the DTS Events, FireProgress, FireInformation, FireWarning, and FireError methods. Using these methods is the answer when everything else fails for one reason or another. I simply call the apprpriate method, and I get output in the Progress window, allowing me to observe script execution without the nuisance of popup message windows (that actually stop script execution while they wait for user interaction).

Dts.Events.FireInformation(suitable parameters)

If you don't know what a DTS package is, google is your friend.