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 |

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 |

Back to some basics today.  These are probably my favorite Visual Studio keyboard shortcuts:

CTRL-K,C – comment selection
CTRL-K,U – uncomment selection

To invoke either command, hold down the Control key while hitting K and then either C or U.  These two are way up on my list because the ability to easily comment large sections of code makes me less likely to delete them when I feel they’re not necessary.  90% of the time I end up deleting the commented code anyway, but it’s nice to have for that other 10%.

There are many more shortcuts that are accessed using CTRL-K plus an additional key.  Here’s a pretty comprehensive list of all the shortcuts in Visual Studio 2003 and 2005.

Share this post: digg it | Email it |

Have you ever generated code at runtime using Reflection.Emit()? Neither have I. It’s very complicated and I haven’t had a compelling-enough reason to attempt it. A developer by the name of Stefan Simek has created a brilliant API called RunSharp (or Run#) which wraps the native C# Emit() functionality with an infinitely easier to use facade.

Let’s say you want to generate a class with a single public method. At design time this is easy enough:

public class MyClass
public void Main(string[] args)
// do stuff

I’m not going to post what it would have been like using out-of-the-box reflection in C#, but let’s assume that it is the giant pain in the ass that it really is. Now here’s the Run# version:

AssemblyGen ag = new AssemblyGen(“MyExecutable.exe”);
TypeGen myClass = ag.Public.Class(“MyClass”);
CodeGen g = myClass.Public.Method(typeof(void), “Main”, typeof(string[]));
Operand args = g.Arg(0, “args”);
g.WriteLine(“// do stuff”);

Share this post: digg it | Email it |

Sweet baby jeebus, what an assbeating of a newsgroup to subscribe to.  If anyone knows of a better group that actually provides tidbits of info without having to wade through 20 posts of “what is a using statement?” please let me know.

Also I’ve decided to split this blog into two – C# and personal.  I decided over the weekend that there’s no sense in preaching politics on a .NET blog.  I’ll post a link when it’s ready.

I learned something pretty cool about .NET attributes today. While I have known about Obsolete() for some time, I just learned about Conditional(). Consider this code:

void ProductionMethod()
void WriteDebugInfo()
   // Display helpful debugging info

Traditionally, the call to WriteDebugInfo() would be enclosed within a preprocessing directive (#IF…#ELSE…#ENDIF) to eliminate the method call when the application is compiled in release mode. The Conditional() attribute replaces that rather ugly style with a single line of code as shown above. The compiler will automatically remove all calls to the decorated method unless the condition is true. This means you can make all the calls you want to WriteDebugInfo() without affecting code readability or production performance!

You may be thinking that this isn’t much of an improvement, in which case you’re wrong. By moving the decision into an attribute, you get all the existing attribute functionality supported by the framework. Want to know how many debug methods exist in your project? Would you prefer to manually search for and count all the instances, or write a few lines of code to reflect over the entire assembly? That’s just the beginning of it.

Next Page »