I’ve been stuck in .NET 1.1 hell for several months now. After working with VS2005 for a while this version is a major step backwards. Part of my problem is that the IDE is buggy and I don’t really trust it 100%. It does flaky things, randomly crashes, and closes toolbars and windows when it feels like it. Unfortunately that means I sometimes jump the gun and blame VS when the code really is the problem. Can you tell what’s next?

Yep, I spent much of this week tracking down an issue with the debugger. Code that worked just fine last week is now dead with no changes made. Stepping though it line by line, it would hang on the same line every time:

PICImagXpress imagXpress = new PICImagXpress();

That’s an imaging component from Pegasus. Once the highlight left that line, the debugger would cease functioning and eventually the caller would receive a timeout error. Interestingly the debugger remained attached to the web process and would resume functioning on the next client call.

After days of trying to track down corrupt assemblies, bad references, and anything else I could think of, I finally created a standalone WinForms app to test the imaging component in isolation. As soon as this line was processed, up pops a dialog box: “Invalid license, please contact Pegasus support at…”

Yep – they included a modal dialog error box in a standalone class library. This box, incapable of being displayed in a Visual Studio class library project, was hanging the app and leaving no way to track it down.

So if you experience a similar hangup problem with VS in the future and have no idea how to fix it, put your components in a separate UI project and test them to make sure they aren’t trying to get your attention.

Download it on April 29.

Believe it or not, there’s a common yet useless dialog in Windows XP:

I’ve never seen it work, and I don’t know anyone who has. If you want to get rid of this annoyance, a quick and easy registry hack exists to make your life easier. Using regedit or your favorite registry editor, navigate to

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\ CurrentVersion\Policies\Explorer

Create a new DWORD value, name it NoInternetOpenWith, and make its value 1. Done, no reboot necessary!

Share this post: digg it | Email it |

From the files of the “never stop learning” department comes a cautionary lesson in performance, courtesy of this blogger.

Often times when you’re comparing strings you want to eliminate case differences from consideration. Some people use ToUpper(), some use ToLower(), and both are equally valid for that goal. So what’s wrong with the following code (other than the fact that it doesn’t do anything useful)?

if(student.FirstName.ToLower() == “ebenezer”)
System.Console.WriteLine(“Sucks to be that kid”);

By itself there’s probably nothing worth addressing. But what if we zoom out a little?

foreach(Student student in schoolStudents)
{
if(student.FirstName.ToLower() == “mortimer”)
System.Console.WriteLine(“His parents must hate him”);
}

Enough suspense. The problem here is that strings are immutable, or unchangeable. That means if you change a string in any way you’re actually creating a new string instance and disposing of the original. That’s exactly what’s happening each time you call .ToLower() on the FirstName string property of the student. Not such a big deal in the first example but potentially a very big deal in the second. If there are 1,000 students in the schoolStudents collection, you’re creating 1,000 extra string instances just for comparing the values – to say nothing of what else you might do inside the if block!

How can you avert this tragic miscarriage of optimization? Easy. Replace the ToLower() line with the following:

if(student.FirstName.Equals(“ebenezer”, StringComparison.OrdinalIgnoreCase))
// do something

The author of the original link ran several test iterations and found that performance is roughly 3 times better with Equals() than it is with ToLower()!

It’s good to go back and revisit concepts that are tempting to dismiss as too elementary. It helps keep the “programmer’s ego” in check and helps solidify your foundation as a competent and skilled professional.

Share this post: digg it | Email it |

Sure, you’re thinking, they’ve been saying that for years.  This time it’s real, even though it may not be much – ICANN announced that on February 4 they will be adding IPv6 records for the addresses of four root servers.  With that change it becomes possible for the first time for two IPv6 hosts to communicate without using any of the IPv4 infrastructure.  Not exactly a revolution but sometimes big changes happen slowly and incrementally.  In a decade every electronic component you own – cell phone, iPod, even your car – will have its own unique IP address, courtesy of this new system. What could possibly go wrong?

Share this post: digg it | Email it |

Karl’s back with part 4 of the series. Today we learn all about the evils of coupling and we’re introduced to Dependency Injection – the slayer of improper coupling.  Proper use of DI allows for cleaner separation of responsibilities which, in turn, creates more resilient and less brittle code. Most importantly it makes unit testing much easier.  You are writing unit tests for your code, aren’t you?

Share this post: digg it | Email it |

Part 3 of Karl Seguin’s Foundations of Programming series is now online. This time it’s all about persistence, mapping between object graphs and relational databases (O/R Mapping), and impedance mismatch.  Read, learn, and never again get bogged down in stored procedure-based hell!

Share this post: digg it | Email it |

Follow

Get every new post delivered to your Inbox.