I've recently started playing with NDepend again.  This tool is a sort of data mining utility for your code.  Feed it your assemblies and it can tell you almost anything about them.  Using a custom query language with a SQL-like syntax, you can dig into all sorts of metrics and useful information. Out of the box, it ships with tons of useful queries for common code problems. 

I ran some of our code through it and got dinged on some of the code complexity queries:

In this case, I had several huge methods that needed to be broken up and optimized.  Thanks to NDepend's prodding, I spent some time refactoring using ReSharper, and whittled those down to 0s:

That's helpful, but not nearly everything that NDepend can do.  For example, the code I'm testing with is involved in some multithreading, so with a little digging through the docs, I came up with this query to show all methods that change state (besides property and event setters), but don't use any locks:

WARN IF Count < 0 IN SELECT METHODS WHERE
!IsDirectlyUsing "System.Threading.Monitor" AND ( ChangesObjectState OR ChangesTypeState ) AND
!IsConstructor AND !IsClassConstructor AND !IsPropertySetter AND !IsEventAdder AND !IsEventRemover

This doesn't guarantee thread-safe code, but it definitely helps drill down to potential problem areas.

Another area I can see us using this in is to provide metrics for our customers.  Generally they are not concerned with things like Cyclomatic Complexity, but some simple numbers may be useful.  We use FinalBuilder, so it's possible we could run NDepend's console utility to roll the numbers into some XML and publish to their customer wiki.  For example, here's a quick query to spit out the total number of tests for a project:

SELECT METHODS FROM ASSEMBLIES "TestAssemblyName" WHERE HasAttribute "NUnit.Framework.TestAttribute"

Once we get a customer set up with these metrics, we'll post more about how to automate that.  Until then, go check out NDepend!

One of the challenges of being a contract software developer is that we often work remotely on a clients' network via VPN.  Each client has their own VPN client, Source Control, and development environments.  In many cases, development platforms just aren't made with this in mind.  It's only as of VS 2005 that you can even switch Source Control Providers easily! If you've ever had to connect to Microsoft SourceSafe over VPN, you know it's still not designed with remote work in mind.  It relies on a network file share, which can be problematic over VPN.  It does ship with a WebService based solution, but this may not be feasible for the client to install in all cases.

The Problem

When connecting over VPN, the main problem is that there is no option to specify the network user to connect with.  For example, you may log in to the clients' VPN, but still attempt to access resources using your machine's local account.  When doing things like mapping drives, it's easy to supply an alternate username and password.  However, with SourceSafe, there is no option to supply network credentials when connecting (which are totally different from the SourceSafe credentials).

The Solution

Enter the Windows runas command.  This command lets you run any application as though it were a different user.  In this case, you want to run Visual Studio as though you were that network user.  To set this up:

• Create an empty text file named "RunVisualStudioAs[DomainUserName].bat"
• Edit and Add the following:
• runas /netonly /user:[Domain]\[User] "C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\devenv.exe"
• Save.

Then, when working on the project, just launch VS using the batch file.  You will be prompted for a password each time, since runas does not allow entering a password in the commandline for obvious security reasons.  But there are 3rd party runas replacements which can help you get around this.

One other word of caution:  Due to the chatty nature of Windows file sharing, this will still be very slow over a remote connection.  Turning off Anti-Virus helps a little, and there are some additional speed tips here. It's definitely not the ideal solution, but it can be done!

For one of our clients, I've been working on converting printed forms into web forms, and in the process have been dealing with a lot of tables that need to fit within a fixed width.  These tables are in a FormView in a User Control, which are then placed on webpages as needed.  I was finding that Visual Studio 2008's design mode was happy enough to accept my fixed-width columns and tables settings in my CSS stylesheet when working on the User Control, but once that User Control is placed on an actual page the fixed-width settings are no longer respected in both design mode and in debug mode displayed through a browser.  What to do?  After much frustration I found the embarrasingly simple answer: I wasn't putting "px" at the end of pixel measurements for table/column widths.  For whatever reason the Visual Studio 2008 FormView designer was content without the "px" but nothing else was.  In my rush to get things working I was leaving off the "px" figuring that I could go back later and add them on after the fact.  So lesson learned: be standards compliant, even if your development tool of choice lets you get away with not being standards compliant.

Still on the topic of fixed-width tables and columns, have you ever wanted to figure out exactly how many pixels wide/tall something is on a webpage, be it a table row, table column, header graphic, etc.?  Enter Pixel Ruler--a free app that displays a rotatable ruler on your screen and even tracks your mouse cursor and keeps a running measurement of how many pixels away you are from the zero mark on the ruler (in one dimension of course--it doesn't do diagonal measurements).  This app will save me countless hours of eyeballing and hoping for the best, instead providing me with precise measurements to the pixel.

One technique we've started using is automating our apps' configuration using Pre-Build Events and Build Configurations in Visual Studio.  It takes a little more work to set up, but once you do, publishing test and production apps is much easier.  It also helps the developer to think not just about a "works on my machine" app, but an app that works on any number of scenarios.  Without this approach, the developer still has to keep up with multiple config files, but typically does so in their head. Scott Guthrie has a great post showing how all this is done.  However, a few tips will help you fine tune your automation, so that development is even more painless:

• Decide the different scenarios your app will run in.  In our case there are typically 3:
  • Local - App is being developed and running on the developers' PC
  • Staging - App is being tested in a copy of the production environment
  • Production - App is "live".
• Create a folder named Configuration.
• Create a .config file for each scenario above.
  • Name the .config file scenario.web.config or scenario.app.config (ie local.web.config).  Using this approach over Scott's means you still get intellisense in the .config files!
  • If you have an existing .config file, just copy it to the Configuration folder and rename it as above.  Remember that after this is set up, the "real" .config file will be overwritten.  If you put blank .config files in Configuration, you'll loose the "real" configuration file.
• Create Build Configurations in Configuration Manager for each scenario above. 
  • In each configuration, add the following Pre-Build event

  • IF EXIST "$(ProjectDir)Configuration\$(ConfigurationName).web.config" xcopy "$(ProjectDir)Configuration\$(ConfigurationName).web.config" "$(ProjectDir)\web.config" /Y /R

  • This script accomodates the naming schema above, and works with source control by overwritting the read-only .config file. Note if your project is a windows forms, console, or class library app, change "web.config" to "app.config"

And that's it - before each build, the appropriate config file will be copied over and used.  Note that you'll never want to change the .config file in your project's root, as it will be overwritten.  Instead, whenever you need to change configuration, decide how the change will affect each scenario, and change each .config in your Configuration folder.

In the slides from Scott Guthrie's 'ASP.NET Tips and Tricks' TechEd Presentation, I ran across this gem.  You can turn off debugging server-wide by adding the following to <system.web> section in the server's machine.config file (typically located in C:\windows\Microsoft.NET\Framework\v<version>\Config):

       <deployment retail="true"/>

This is a great backup in case developers forget to turn it off in the application using <compilation debug="false"/>.  Scott also mentions a few of the negative results of forgetting this little setting:

• Slower performance due to debug code
• App uses much more memory
• Client-side scripts are not cached

One of the most useful tools for .NET development is Lutz Roeder's .NET Reflector, now in version 5.  It uses reflection to peek inside .NET assemblies and disassembles the IL back into C# or VB code for those times that you need an in-depth look into any .NET library.  Ever wonder what the code for System.String looked like? This release adds some really nice features:

• Formatted code comments- doubles as a documentation browser for XML code-commented members
• 'Expand members' in disassembler lets you see code for an entire class at once- previously you had to look at each method separately.
• New analyzer features shows where classes are instantiated and exposed.
• Search Google or MSDN for a member

In addition to helping you debug code, this is also a great learning tool.  What better way to understand framework development than to peek inside The Framework itself?