Attention: We are retiring the ASP.NET Community Blogs. Learn more >

The Simple Things

Don't you hate working on a complex problem only to stumble on something so simplistic you just feel like a dolt? Today (more like yesterday, given the early hour EST), I realized the solution to a problem I was having with a winform combobox derived class.  The problem? Whenever I tried to compile in release mode, the visual representation of the control would disappear from the winform designer, and the app would not compile. As is usually the case with strange problems, the solution came while I was away from my keyboard... on the way to work.

It turns out I was referencing the exe file to get the combobox derived control in the toolbox, just to save time until I refactored it into a separate controls project. This is obviously a poor programming choice.  Never put off until later what you can do today; doubly so for programming. So what was happening was as it compiled, it overwrote the exe file (or perhaps just deleted the exe file) that was referenced, the designer saw it, and removed the control from the page for me (how considerate!), which took away the ability to compile.

This is one type of post I always enjoy reading from other people.  Their experiences serve to enlighten people in the art of programming, without focusing just on the “coding” aspect.  For example, Julia Lerman talks about some of her experiences cold-programming WSE here.

4 Comments

  • I was having a problem deploying my app to it's server. Whenever I deployed a change, either an ASPX or code behind DLL, the app would lock up. I'd have to contact the sys admin and have him bounce the web service completely. I spent two weeks troubleshoot my application and trying to tweak every line of code and stored procedure because he assured me there was nothing wrong with the server.



    I'm finally convinced that my code can't get any tighter and that there must be something wrong with the server. The sys admin humors me and terminal services into the server. We notice that the CPU util. is pegged at 100%, in fact it's so pegged that not only are the green bars at 100% but the red bars are hovering at around 70-80%. So we immediately look in the process list and notice that "XXXXX.scr" is using ALL of the processor time. Turns out he had written and installed a Flash 5 screensaver on the server and had it running in the locked admin account on the workstation.



    The moral of the story: It's not always your code that is bad.

  • We call that experience of realizing the simple after believing it is complex, an "epipha-duh" (think, epiphany). Thanks for sharing!

  • hehehehe, back when I was planning on going to med school in college we called it "hearing hoofbeets and thinking zebras instead of horses."

  • Scott, re: the screen saver. Generally anything with an scr extension should be avoided like the plague :). That's a great story...just out of curiosity, how long was the screen saver running before it was caught?

Comments have been disabled for this content.