Visual Studio Tips

CodeGaffe: Copy & Paste (and ReSharper to the rescue)

Dave Chestnutt — Mon, 11 Dec 2006 18:22:00 GMT

I use a coding tool called ReSharper - and I was pleasantly surprised the other day when it pointed out a copy & paste bug that was waiting to explode. You see, copy and paste programming is so very easy to do - that we all do it. Even the best of us accidentally leave in duplicate code snippets from time to time.

Why Cut & Paste is so bad

There are two big reasons why this is an anti-pattern:

If the code you cut and pasted has a bug in it (and it invariably will), what do you think are the chances that you'll find and fix all occurrences of it?
If you're rubber-stamping code (copy and paste, paste, paste…) so that you can make minor edits to the pasted version, it's too easy to make a mistake - and the code will compile fine. It won't fall over until a customer runs it. Rubber-stamping typically happens in a switch statement or a batch or if/else-if statements (where the cases are nearly identical).

It's this second case that ReSharper showed me a bug that wouldn't have been found until run-time. It surprised me because ReSharper doesn't look for duplicate code snippets. But one of its rules can get triggered if you copy & paste code incorrectly.

ReSharper is...

This is an add-in to Visual Studio. It does many things, but one thing it does well is point out flaws in your C# code via highlighting - so you can quickly see suspicious or questionable practices. There are other tools that do the same for C#, and there are similar tools for Java. [Disclaimer: I do not work for JetBrains. I paid for my own copy out of my own pocket. I'm just a happy user.]

This is not a tutorial on using ReSharper - I'm just showing one tiny example of how it can help you. Here is some legacy code opened in Visual Studio with ReSharper:

Notice the highlights on the right of the source window. Those give an indication of where there might be problems in the source. You can click those lines and it will jump to the place in the code with the problem. It highlights the error and offers fixes, too. The orange lines are approximately lined up with where the scroll bar would be when you view the code. Orange means warning, and red means error. Opening up legacy code often shows many many orange lines because ReSharper warns about suspicious or bad practices. These are things that the compiler is happy with, but you'll be unhappy about in the long run.

Here's what ReSharper found

So, back to how I was pleasantly surprised. Look at this code example. It's pretty obvious at first glance that this code was rubber-stamped to handle many cases - with slight edits in each version.

This code will compile, but it won't work right. Here's what it looks like in normal Visual Studio:

Do you see the problem? It's in line 41. When copying and pasting, the person forgot to modify the if statement to use htmlButtonMatch instead of htmlTextboxMatch. It's clearly wrong, but it might not show up as a bug until months after someone wrote this.

Look at what ReSharper shows (it does additional highlighting of things like method names, etc.):

With this cool tool, I'm immediately alerted to the problem. The tool tip for the grayed out variable warns me that it wasn't used. From that, I can easily spot the error in line 41. The important thing is that ReSharper alerted me that there was a problem.

This was some actual legacy code that I opened up one day - when I noticed the problem. I was fix it and find out why unit tests didn't cover this case.

You know, if I didn't tell people I used ReSharper, they'd think I was really smart.

But I am smart enough to use good tools.

See also: http://en.wikipedia.org/wiki/Copy_and_paste_programming

Technorati tags: Visual Studio, CodeGaffes, Geekswithblogs

Gotcha! Visual Studio Pre/Post-Build Events

Dave Chestnutt — Tue, 30 May 2006 16:23:00 GMT

Visual Studio has a nifty feature called Pre-Build and Post-Build events. These are used to include extra DOS commands before or after the build.

But there's a gotcha! And it will bite you when you least expect it. In Visual Studio, there is NO ERROR CHECKING except at the end of an event. Any errors that happen prior to the final step are lost. Keep reading to see a workaround.

Setting Build Events

Build Events are accessed by right-clicking on a Project in the solution explorer and choosing "Build Events":

It looks like these were originally intended as one-line DOS commands to do tweaks in your build. But they obviously grew - and you can put any number of DOS commands in there to copy files, clean up directories, even run unit tests!

Before describing the gotcha, there are a few things you need to know if you've never used these before. One is that you can put any DOS commands in here. It's really nothing more than a place to save a batch file that's run before (or after) the project build. It also offers "macros". The build process actually creates a batch file from your commands by replacing the macro text.

In this example, MYDEPLOY is just a regular DOS environment variable. The advantage to macros is they take into account the various differences between developers (and their file directory structure) as well as handling Debug vs. Release builds.

For example, this command:

Copy $(OutDir)*.* %MYDEPLOY%

Gets converted to this, and placed in a batch file:

Copy bin\Debug\*.* %MYDEPLOY%

The Gotcha

So, what's the problem?

Well, VS puts these commands in a batch file and runs it. VS checks for build failures so it can tell you about them. However - it only checks for a failure of the batch file that it created - not for any failures within the batch file.

What does this mean? If you only place one command in the build event, VS will correctly report any errors that happen. But if you place multiple commands in here, the net effect is that VS will only detect an error in the last statement.

So, for example, if you put three copy commands in here, VS will only report an error if the final command fails.

Ouch.

The Workaround

So how can we fix this? Since VS is just creating a batch file, we use normal batch file commands to detect errors and report them. Here's what I do:

I add a check for error after every meaningful step:

if errorlevel 1 goto BuildEventFailed

I add code at the end to handle the error so VS will report it:

REM Exit properly because the build will not fail

REM unless the final step exits with an error code

goto BuildEventOK

:BuildEventFailed

echo POSTBUILDSTEP for $(ProjectName) FAILED

exit 1

:BuildEventOK

echo POSTBUILDSTEP for $(ProjectName) COMPLETED OK

Here's an example of one of my actual post build events:

echo POSTBUILDSTEP for $(ProjectName)

xcopy "$(TargetPath)" "$(SolutionDir)$(OutDir)" /i /d /y

if errorlevel 1 goto BuildEventFailed

xcopy "$(TargetDir)$(TargetName).pdb" "$(SolutionDir)$(OutDir)" /i /d /y

if errorlevel 1 goto BuildEventFailed

echo GAC of: "$(SolutionDir)$(OutDir)$(TargetFileName)"

gacutil.exe /nologo /i "$(SolutionDir)$(OutDir)$(TargetFileName)" /f

if errorlevel 1 goto BuildEventFailed

REM Exit properly because the build will not fail

REM unless the final step exits with an error code

goto BuildEventOK

:BuildEventFailed

echo POSTBUILDSTEP for $(ProjectName) FAILED

exit 1

:BuildEventOK

echo POSTBUILDSTEP for $(ProjectName) COMPLETED OK

You don't have to be as fancy, with the extra "echo" statements, but do the error checking you need so errors don't slip through the cracks.

One final note: don’t put too much in these events. They’re pretty hard to debug when things go wrong. If you have something complex to do, put the commands in a batch file and reference the batch file yourself in the event.

But now at least, you can get notified if (make that when) something fails.

Technorati tags: Visual Studio, CodeGaffes, Geekswithblogs

CodeGaffe: Avoid .NET “partial” classes in C# and VB

Dave Chestnutt — Wed, 05 Apr 2006 23:34:00 GMT

Microsoft added a new keyword to C# and VB for 2005 (CLR 2.0): partial

Don't use it.

partial is used to physically break up a class definition into multiple files. When the compiler sees the keyword partial it finds all the related partial files in order to compile the class. This makes it possible to split the code for a single class across multiple files. By and large, though, this is a bad idea. Let’s look at why that is.

If you find
yourself typing
"p-a-r-t-i-a-l"
Stop!

Reasons Given To Use the “partial” keyword

There are three main incentives I’ve heard for using partial, according to Microsoft and others:

If a class is really large, break it into multiple files so more than one person can work on it at a time.
If a class implements multiple interfaces, put the methods that implement each interface into a separate file.
When the IDE generates code, it puts the code into a separate file so you don't see it or accidentally modify it.

Let's examine each of these reasons in detail.

1. Avoid using “partial” to break large files into many smaller files—so multiple people can work on them. This is a bad practice.

Why?

No matter how you try to group code in various partial files, you will never see the big picture for the class anymore. It’ll become brittle, easily broken. By only viewing a portion of the class, you can too easily break some assumption or dependency in the rest of the class. For example, you won’t see all the internal fields. If a field needs updating, and it’s not referenced in the portion of the class you’re editing, you’ll never even realize that you are breaking the class. People will make incompatible changes and no one will know until Humpty Dumpty is put back together again. Are your unit tests good enough to catch this?

So what's the right solution for really large files?

If you’re thinking of using partial because your class file is large, then consider it a warning sign that it's time to break the class up—not by using partial but by using object oriented design. Break your monster class into multiple classes, grouped by responsibility. That way, you can hide details inside classes, and it will be much harder for developers who work on the new smaller classes to make incompatible changes with each other. As a bonus, breaking it up will also make your code easier to read, test, and maintain.

2. Avoid using “partial” to organize your class file. Some people suggest putting the implementations of each interface into their own files. This sounds reasonable at first, but it contains a pitfall—the class implements 2 or more interfaces, but it is still one class that has its own private data (and all the assumptions that go with that). If you only read code in one file and make changes, you may not realize the side effects you introduce on other methods that are in other partial files. This is a bad practice for the same reason that it was for reason #1, large class files.

3. “partial” is ok if the compiler puts it there. This is the only safe reason to use partial. When the compiler adds partial to your class, it does so to hide the code that it generates. While there are other solutions to handling generated code, this is the one that Microsoft chose, and it works fine. You can't ever modify the generated code (well, not easily) so it's just as well that it's hidden in a separate file. Note the key phrase here: the compiler adds partial—not you.

Recommendations

If you find yourself typing "p-a-r-t-i-a-l" — stop! Don’t do it.
If the class you’re working on is marked partial, make sure that the other partial bits are compiler-generated. If they’re not, you should consider putting the class files back together and re-factoring the large class into smaller classes.

One final Note: in VB, since the partial keyword is optional, you can really confuse someone reading the code because they may not even realize that other code exists for this class. If you work in VB, be aware that your entire class may not be in the file you’re looking at.

For another viewpoint, see these articles:

This is a well written article describing partial classes: http://www.devx.com/dotnet/Article/22603
Microsoft’s article on partial (and other things): http://msdn.microsoft.com/msdnmag/issues/06/00/C20/default.aspx

Technorati tags: C#, Visual Basic, Visual Studio, CodeGaffes, Geekswithblogs

NUnit - support both .NET 1.1 and 2.0 at the same time

Dave Chestnutt — Tue, 07 Mar 2006 23:44:00 GMT

How to easily run NUnit tests in both .NET 1.1 and 2.0 environments.

I want to run my NUnit tests! But I have a problem -- my code runs under both .NET 1.1 and 2.0 frameworks. It is real easy to run tests from the IDE, which I do, but that means I'm only running the tests under one version of .NET.

How can I easily run tests under both .NET frameworks?

I'm lazy, so it has to be easy. So, without even resorting to the command line, here's how I do it in 3 steps:

1. Running tests with the .NET 1.1 Framework

I use Visual Studio 2003, and the TestDriven.NET Add-in (http://www.testdriven.net/). I right-click on tests, projects, or the whole solution - and run my tests under .NET 1.1.

2. Running tests with the .NET 2.0 Framework

I use the NUnit GUI app to run tests under the .NET 2.0 environment. To make the NUnit GUI run with .NET 2.0 framework - I modified the nunit-gui.exe.config file so its startup section has the 2.0 runtime first:

<startup>
  <!-- NUnit will run under the first version it finds -->
  <SUPPORTEDRUNTIME version="v2.0.50727"/>
  <SUPPORTEDRUNTIME version="v1.1.4322" />
  <SUPPORTEDRUNTIME  version="v1.0.3705" />
  <REQUIREDRUNTIME  version="v1.0.3705" />
</startup>

I place a shortcut to the NUnit GUI on my Quick Launch toolbar, and I'm all set. While it's still true that I run the tests in the IDE the most, I can easily start the NUnit GUI and fire off my tests under .NET 2.0. And since it's easy, I do it.

3. Making a test conditional based on .NET framework version

Some of my tests only make sense under .NET 2.0, and some under 1.1. [They all compile under 1.1 because we support both.] So how do I make a few tests conditional? This requires two things: How to detect the version of the framework in use, and how to stop NUnit from running tests that are inappropriate for the framework in use.

I've seen a bunch of ways to detect what framework version we're actually running under. This is my favorite because it's so simple and clear:

public bool IsUsingDotNet11()

    return (Environment.Version.Major == 1)

        && (Environment.Version.Minor == 1);

public bool IsUsingDotNet20()

    return (Environment.Version.Major == 2)

        && (Environment.Version.Minor == 0);

As far as NUnit goes, we let it run all the tests, because we add checks inside the tests to stop them if they require the "other" version of the framework. By using NUnit's Assert.Ignore() method, we can give a nice message, as well as gracefully stop the test in its tracks.

[Test]

public void TestSomethingOnDotNet11Only()

    if (! IsUsingDotNet11())

        Assert.Ignore("This test is for .NET 1.1 only");

    // … Rest of test code ...

There you have it. You can adapt this technique to suit your needs. For example, if you run your tests from a batch file, you can modify nunit-console.exe.config to make the console run under any version of the Framework that's installed on the machine.

The reality is that many of us have to support more than one version of the DotNET framework. Until such support is built into Visual Studio, we'll have to resort to methods like this to test in the real world. Hopefully this short cut will make it easy.

So you can be lazy like me.

Visual Studio and Perforce: Suppress the Open Connection dialog

Dave Chestnutt — Tue, 28 Feb 2006 20:14:00 GMT

We've used Perforce source control for a number of years. It's a great tool and it integrates with Visual Studio pretty well. But its Visual Studio integration has one really annoying feature, that fortunately, you can work around.

The feature is this: If your solution has 10 projects in it, you can put each of those 10 projects in a separate Perforce Depot. Is that useful? I'll leave that to you. Suffice it to say that we put all our source in one Depot.

The problem comes when you reload a solution. Perforce, by default, wants to prompt you for login information - for each project in the solution. We have some solutions with 20-30 projects, so this gets pretty annoying.

This is the Perforce "Open Connection" screen that pops up over and over again:

Fortunately, you can suppress this dialog (assuming that you only use one Depot!) The option is pretty well hidden, but here's how you get to it. Open Visual Studio, and before you open your solution file, go to Tools - Options. Select SCC provider on the left, and click the Advanced button:

This brings up the well-hidden Perforce dialog. Switch to the Connection tab and click the option called: "Bind to the workspace that matches your Perforce environment settings"

Presto! Press Ok to save your settings, and the Perforce "Open Connection" screen is banished, never to annoy you again.

This makes the Perforce integration fairly practical in Visual Studio. It's not perfect, but it automatically checks out files for you (as you try to change them). And that's extremely useful.

It just makes my day...

Visual Studio: Macro to automatically collapse the projects in the Solution Explorer

Dave Chestnutt — Tue, 21 Feb 2006 21:02:00 GMT

One of the pains of working with Visual Studio is that the Solution Explorer, in a large project, is hard to use. As you open more and more files, it gets harder to navigate in the solution explorer since it opens all the projects for you.

Edwin Evans wrote a nice short macro to collapse all the projects. It works with both 2003 and 2005.

http://www.codeproject.com/macro/collapseall.asp?df=100&forumid=7565&exp=0&select=396167

Assign it to a button your toolbar and give it the smiley face icon. 'Cuz that's what you'll do when you use it.

SparklingCode: Count the cost with Line Numbers

Dave Chestnutt — Tue, 31 Jan 2006 00:46:00 GMT

One of the benefits of using modern editors is that it's really easy to navigate your code base. If you're looking at a method call, for example, you can use a keystroke combination to jump to the method definition.

But there's a drawback to this.

If you're not careful, as you add new code you can end up with monster methods, or monster-sized classes. Let me ask you this - what do you think the maximum size of a class should be? 100 lines? 500 lines? 10,000 lines? While we won't agree on an exact number, we can all agree that a class with 10,000 lines in it is much more likely to have bugs in it than one with 100 lines.

But no one sets out to write such a huge class. How does it get this way? Simple - over time, various people make little modifications to a class. How many times have you looked at a modification and thought to yourself, "Perfect, I'll just add these lines of code here, and it'll support the new feature." After enough people do that, your 500 line class grows and grows. And grows!

Here's a fairly innocuous bit of code. If I had just added this, without line numbers being displayed, I might not realize how big the class already is. But, as the screen shot on the right shows, I might be more inclined to realize that I shouldn't grow this class any further since it already has nearly 20,000 lines of code in it!

No Line Numbers	Line Numbers show a problem!

Thus, my advice: turn on line number display in your editor. In Visual Studio, turn on Line Numbers by going to Tools | Options | Text Editor and check Line Numbers

Now, when you're fixing bugs or adding features, you'll see line numbers. And when you get near the bottom of a file, you'll have another reminder that the class is growing out of control. Then you can plan some refactoring to break up the monster method or class. And improve your code base.

Turn on line numbers in your editor. They're an early warning system.

Technorati tags: CodeGaffes, Geekswithblogs