Over the years, every developer builds up an essential suite of tools for designing, debugging, building, analyzing, testing, and otherwise manipulating code. This chapter is about just a few that I have found most useful. Consider these a starting point.
Because URLs are prone to change over the years, I am omitting download links for these tools. You should be able to easily find them using your favorite search engine
Originally developed by Lutz Roeder, Red Gate now maintains and furthers this handy little utility that distils .NET assemblies into source code (your choice of C#, VB, IL, and more).
I use this mostly as an educational tool for seeing what the .NET Framework library is doing internally. It’s generally a bad idea to rely on implementation details, but sometimes it’s nice to know what native API the Framework uses—as an instructive example. Reflector is shown in Figure A.1.
Whether you use test-driven development or not, having a solid set of unit tests can give you a lot of assurances in code quality and the ability to refactor when necessary.
NUnit includes a library to annotate source code as tests, as well as a GUI and command-line harness to run the tests.
As an example, let’s see some tests of an incomplete ComplexNumber
class:
In a separate assembly, you then define the test class:
The test runners load the assembly and discover each test, allowing you to run them. Green means good! NUnit is shown in Figure A.2.
Although you can and should install NUnit into your local system, you should also copy the main NUnit binaries into a subfolder in your project, especially if you are using a source code control system and/or automated tests. This ensures that other developers (or your future self) don’t need to install additional tools once they retrieve the source code: It’s all a self-contained package.
All editions of Visual Studio now include built-in unit testing tools with the classes in Microsoft.VisualStudio.TestTools.UnitTesting
namespace. It does not have all the feature of NUnit or other competing products, but it does have the advantage of being fully integrated with Visual Studio. In addition, some editions of Visual Studio include other analysis tools like code coverage that can use the built-in unit testing.
NDepend is such a powerful program that it’s hard to describe everything it can do. It can show at a glance where the largest or most complex parts of your program are. It can show you dependencies among classes or assemblies. You can give and even create custom queries to report on—for example, all methods starting with “Do” that have more than 15 parameters and a cyclomatic complexity greater than 2.6. NDepend is shown in Figure A.3.
Some editions of Visual Studio also contains analysis and code metrics tools, but they are not as extensive as NDepend.
This tool is a good sanity check on your code to ensure you’re following best practices wherever feasible. It can analyze your code, recommend changes, tell you if the recommended change is breaking, and point you to more information about why the change was recommended.
There is also an SDK where you can create your own sets of rules particular to your company or project.
I ran the tool on the ComplexNumber
class mentioned earlier in this chapter. As you can see in Figure A.4, it had a few recommendations.
It is very difficult to maintain computers with all possible operating systems on which your application must run. Rather, install them all in virtual machines. This is far more convenient for testing software because you can do it all on your desktop.
Virtual PC is free (as of this writing), but you must have licenses for the operating systems you install (see Figure A.5). If you have Windows 7, you can get Windows Virtual PC, instead.
For best results in a virtual machine, have a lot of memory available. I have 8GB of RAM in my development desktop, which means I can dedicate fully 2GB to a virtual installation of Windows 7, for example. To take advantage of this much memory, you must be running a 64-bit version of Windows.
SysInternals (now owned by Microsoft) produced some gems of utilities, and the two I use most are Process Explorer and Process Monitor.
Process Explorer, shown in Figure A.6, is sort of like a super version of the Windows Task Manager. In addition to processes, it can show you threads, which process has open handles on a file, performance information, and for .NET processes, numerous CLR counters.
Process Monitor, shown in Figure A.7, is a real-time trace of file, registry, network, and process information. You can use it to see how a process is using the file system, for example, or where in the registry it is writing.
Yes, you could easily build a regular expression tester yourself, but the ones already out there offer some not-so-trivial features. RegexBuddy, shown in Figure A.8, is one of the best, but there are others.
Among other things, they offer menus for inserting subexpressions, explain the expressions in English (or close to it), give instant graphical feedback, provide syntax highlighting, and more.
This application is kind of like RegexBuddy for LINQ. It has a tight interface that lets you quickly test out LINQ queries against databases.
LINQPad also lets you just test out quick code snippets to see the results, without having to create dummy test project. Figure A.9 shows the tool in action against our Books database from Chapter 13, “Databases.”
There are many “ultimate tool lists” on the Internet, but probably one of the most famous is Scott Hanselman’s Ultimate Developer and Power Users Tool List for Windows. Updated at least every year, I encourage you to check it out at www.hanselman.com/tools.