Thoughts in the Wilderness

Interesting article/speech from Charles Petzold. My favorite quote:

“So, day after day, several times a day, I dutifully delete 99% of the emails I receive, and when I’m not able to get at my email for a few days, I’ll leave the machine at home running to pick it up every 10 minutes so I don’t overflow some capacity somewhere, and just the other day I caught myself wondering who will clean out my Inbox after I’m dead.”

Programming in VB.NET, we have a choice of being forced to cast our variables to the correct type, or having them implicitly converted. “Option Strict” is the option that forces us to manually cast variables.

Example non-strict code:
dim textBoxName as String = "TextBox1"
dim txt as TextBox = myForm.Controls(textBoxName)

Example strict code (differences highlighted):
dim textBoxName as String = "TextBox1"
dim ctl as Control = myForm.Controls(textBoxName)
dim txt as TextBox = DirectCast(ctl, TextBox)

The cons are that the strict code is longer, and (some might say) a little harder to read. The pros outweigh the cons though, because:

• the strict code is explicit in its meaning – it is clear that the programmer knew that ctl was not necessarily the correct type, but also had an expectation that ctl is in fact a TextBox.
• if an error occurs (InvalidCastException), and the control is not a TextBox, then the strict code makes it immediately obvious where the error is, whereas the error could be interpreted mean something else in the non-strict case (perhaps textboxName is not the correct type, or perhaps there was an exception within the call)
• my own laziness drives me to avoid explicitly casting to TextBox more than is necessary, thus leading me to refactor my code to do it only once. Thus, I will likely have a single possible point of failure if the type conversion fails, i.e. a better design.

I have not looked at the IL, but I suspect that Option Strict is also more efficient, as it leaves less guess-work for the compiler.

That is, 816970 on the Microsoft website, appears to be fixed in .NET 1.1 Service Pack 1. Curiously, this fact is completely absent from any other location on the Internet, so I am recording it here for the benefit of others that may encounter the problem.

This came in useful recently, trying to debug .NET assembly resolution problems over a dial-up connection. It was not practical to copy the whole 100MB SDK across in order to access the fusion log viewer, so I managed to get it working with only the following 2 files:

• fuslogvw.exe
• msvcr71.dll

…both out of c:\windows\Microsoft.NET\Framework\v1.1.4322 on my own machine.

1. Compile, then copy the .NET dll, tlb and pdb file from your project bin folder to the directory where the “registered” version is.
2. Run the COM exe, and make use of any .NET functionality (does not have to be yours, it just needs to access something .NET before you can do the next step).
3. In VS.NET, go to Tools/Debug Processes and attach to the running EXE