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.


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 |

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 |

This tip comes courtesy of the .NET Tip of the Day site.

If you work with Visual Studio for ASP.NET projects, chances are you’re intimately familiar with the behavior of Solution Explorer – specifically the fact that it opens webforms in design mode when you double click on an aspx file.

If you prefer instead to see the code by default go to Tools -> Options, then HTML Designer.  Change the selections for the types you want to modify and have fun coding!

Share this post: digg it | Email it |

Microsoft MVP Karl Seguin is in the middle of a multipart series named Foundations of Programming. If you are a professional .NET developer, you need to know this stuff.  While DataSets and DataGrids are great tools for relatively simple tasks, they just aren’t robust enough to carry forward into the world of enterprise development. The Object Oriented fundamentals in part 1 and the Domain Driven Design method explored in part 2 are tried and true solutions that many Java, Smalltalk, and other OO developers have been refining for years. The upcoming articles in the series are sure to introduce many more important concepts that have only recently begun to gain traction in the .NET world.

Go give it a read.  I promise that if you take the time to truly understand the topics Karl covers, you will be a much better developer as a result.  That’s my money-back guarantee!

Share this post: digg it | Email it |

If you’re an MSDN subscriber, Christmas has arrived. Visual Studio 2008 and .NET Framework 3.5 have officially shipped.  Right now, not having looked at it, the coolest feature I’m aware of is that Visual Studio 2008 is finally backwards compatible, except for those of us still stuck in 1.1 land.  2.0 and up should be supported natively without having to run any conversion wizards.

@EchoBlog OFF

P.S. Sorry for the long gaps between posts.  There isn’t much to write about since I’m currently neck-deep in .NET 1.1/SOAP/Biztalk 2004 land.

Share this post: digg it | Email it |

Next Page »