NDepend

I received an email the other day from Patrick Smacchia, the lead developer of probably the best known .NET dependency analysis tool NDepend a couple of days ago, letting me know that version 3.0 is now available.

It also pricked my conscious that a fair while back Patrick had given me a license for NDepend v2.0 and only asked that I post about my experiences using it. It is now way overdue for me to return the favour… so what are my thoughts?

First of all, what is it? As I understand it NDepend is a static analysis tool that looks at the dependencies between classes and assemblies. Whereas FxCop might look at individual lines of code to detect sub-optimal patterns, NDepend takes a step back and looks at the big picture of how your application is architected – especially how loosely coupled (or not) your classes are (which is normally a desirable aim).

Probably the main thing I like about NDepend is the dependency graph it can generate. I’ve found this useful both for getting a thumbnail sketch of your current solution (especially if it has evolved a bit over time), and also to a rough idea of the architecture of a legacy application that you’ve just been handed.

One other feature that appeals to my sense of keeping your code in good order is how it can highlight potential version mismatches between assemblies and also symbol files. When your build process becomes slightly more complicated this can be handy to ensure all your ducks are in the right row and version :-) The version differences may not be a problem for compiling and linking, but if your PDB file is wrong then you’re going to get misleading or minimal stack trace information – something better avoided in the first place.

The final feature that can be quite illuminating for me is the dependencies matrix. This is a table (matrix) that shows the interdependencies between all your assemblies. Because it adds up the totals, you can quickly identify where an assembly may only have one (or even no) hard dependencies on another assembly and consider refactoring to reduce your coupling if appropriate.

There are also features of NDepend that to be honest I’m happy to know are there but haven’t had a chance to make use of in a real way yet. It has a very comprehensive inbuilt query language, and could add some real value to a continuous integration build system – where you’re keen to set some code quality benchmarks.

If you’re still not convinced, there’s a whole bunch of demo and tutorial videos on the NDepend site that can explain the range of features a lot better than I can.

Version 3.0 adds new features including:

• Better integration with Visual Studio, including support for VS 2010
• NDepend projects can now be a part of a Visual Studio solution
• Improved performance
• Integration with Reflector

In summary I have found NDepend to be a really useful tool to have in my toolkit, and I’d like to thank Patrick and his colleagues for the opportunity to have access to it.

Changing the location of "Import Pictures and Videos using Windows"

For some reason, if you uncheck the “Prompt for a tag on import” under the “Import Settings” of the Windows 7 “Import Pictures and Videos” wizard, then as far as I can tell there is no way to get back the “Import settings” dialog again.

A quick search of the registry reveals that these settings are stored under the following key: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Photo Acquisition

For example, there’s a “Camera and Portable Device” subkey with a value named “RootDirectory”, and also one named “FilenameTemplate”. Changing these should alter where the wizard saves photos.

Comparing this subkey with the “OpticalMedia” and “Scanner” subkeys showed one interesting difference. All three have an AcquisitionFlags value, but the latter two had it set to 0x82 whilst the former was 0x8a.

Reverting the AcquisitionFlags value to 0x82 in the following registry key seems to restore the import wizard to prompting you for an optional tag, and allowing you to click on the “Import Settings” link again:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Photo Acquisition\Camera and Portable Device

To make this change yourself, follow the following steps (with the standard warning that editing the Windows Registry incorrectly can completely mess up everything!):

1. Run regedit.exe
2. Navigate through the registry tree to find the following subkey: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Photo Acquisition\Camera and Portable Device
3. Double-click on the “AcquisitionFlags” value
4. Type in “82”
5. Click on “OK” and close the Registry Editor

ReSharper 5 – Structural Search and Replace

I found a use today for a new feature that will be in ReSharper 5.0 - “Structural Search and Replace”. Essentially it’s a way to add code matching templates into R# to add new refactoring patterns in addition to those that come in the box.

For example, Microsoft recommends (and Code Analysis/FxCop generates appropriate warnings) if you are doing a comparison between a string value and an empty string, to use the String.IsNullOrEmpty() method.

I always wanted R# to make this change for me, and now I can:

1. Go to Resharper

   Tools

   Patterns Catalog

2. Click on ‘Add Pattern’
3. Enter “$value$ == "" “ in the Search Pattern textbox.
4. Click on ‘Add Placeholder’ and add an ‘Expression’ placeholder named ‘value’ of type System.String
5. Enter “string.IsNullOrEmpty($value$)” in the Replace Pattern textbox
6. Ensure Pattern Severity is set to at least ‘Show as suggestion’
7. Click on ‘Add’

R# will now use this pattern and highlight code that matches. You can then hit the QuickFix shortcut (Alt-Enter by default) and get a smart tag offering to refactor/replace your code.

If you can’t wait for the final release of ReSharper 5 (due in the next few months) then install beta 2 or one of the recent nightly builds.