Turning on Visual Studio 2010 Code Analysis in a machine-independent manner

So you want to turn on Visual Studio 2010’s Code Analysis option but someone on the team rightly points out that this adds a machine specific directory to the .csproj file. Machine specific settings shouldn’t be in a shared project file (.csproj is typically shared).

Visual Studio 2010 uses MSBuild. MSBuild has lots of built in (“reserved”) properties. For instance, $(TEMP) will evaluate to the environment variable for temp.

Fortunately Visual Studio defines a property $(DevEnvDir) that, with slight modification, can point to the ruleset file required for Code Analysis in a machine-independent manner.


MSBuild Reserved Properties

Visual Studio Integration with MSBuild

Macros for Build Commands

Command Prompts with Date and Time

I spend a lot of time in command prompts and have found it useful to have the date and time associated with a given command. It’s great for comparing “how long does this take” especially after the fact. To add this to your command prompt on Windows 7 (and probably XP and earlier versions), change the PROMPT environment variable ala:

PROMPT=$d $t$_$p$g

I usually set this as a user environment variable. These can be set by typing Start then entering “sys env” (no quotes). The first option should be “Edit the system environment variables”. Add a new user environment variable named PROMPT with the value specified above.

PROMPT syntax is described at the online docs for the prompt command.

While the date and time displayed don’t account for the amount of time it takes to type in the command (with very long commands this can be a few minutes) it’s usually a good indicator.

ReSharper 7

Finally getting around to looking at ReSharper 7. Excited so far by these features:

  1. The new “generate” feature. Type Alt+Ins and a menu pops up offering, among others, to:
    1. Generate a constructor. This was already available in ReSharper 6.
    2. Generate Equality members. Very handy when reference equality simply won’t do.
    3. Generate Equality Comparer! This is way, way, waaaayyy too cool. Even though .NET has had Equality Comparers for ages I still see code littered with someStringVar.ToUpperCase() statements! This is error prone because it requires everyone to know in advance which case they’ll need to use. For a dictionary this might mean failing to find a key. Equality Comparers explicitly define what equality means for a type.
  2. You can make a bunch of variables public or private by selecting them in the source editor then clicking the hammer icon that appears. This brings up a menu that allows you to change the visibility.

So what’s this IntelliTrace thing all about?

Just read through an excellent series on IntelliTrace over at The Ultimate Visual Studio Tips and Tricks blog. It’s a 4 part series that explores the rationale behind a product like IntelliTrace and describes how it can be used.

Noteworthy Points

  • It used to be called “Historical Debugging”
  • It introduces some restrictions on Edit and Continue if you enable call tracing.
  • It has to be on when the process being traced is started. This is because it injects code when a process’s MSIL is JIT-ed into native instructions. This only happens once: the first time a block of code executed.
  • It’s a .net 2.0+ thing supporting C# and VB.net apps. Once again, sorry C++!
  • It’s pretty much the only way to debug Windows Azure apps.
  • It can be used in IIS via powershell, VS Test Manager, SharePoint.


The Events tracking reminds me a lot of process monitoring tools in SysInternals. Events of interest are operations that tend to be sources of error:

  • opening the wrong file.
  • writing the wrong value to a registry key.
  • binding the wrong parameter to a sql command.
  • parsing xml files that have errors in them.
  • et cetera…

There are many ways to write code to do any one of these operations. IntelliTrace comes with a predefined list that covers most (if not all). That is, IntelliTrace synthesizes all of the ways to open a file (by path string, by FileStream, etc…) into the concept of an Event (opening a file) and identifies every point in the execution of a program that a file was opened.

In this way IntelliTrace strikes me as operating at a higher level of abstraction than traditional (or live in the parlance of the series) debugging. Traditional debugging is about the call stack, locals, watches and breakpoints. IntelliTrace Events is temporally oriented and is all about groups of operations that tend to be sources of execution errors.

Logic Errors, where a program doesn’t exhibit faulting behavior (e.g., reading a file that doesn’t exist) but does not behave as intended, require the much more heavyweight (with respect to performance impact) IntelliTrace Calls tracing. Calls and their parameters are traced. IntelliTrace provides some filters to weed out sources of noise (e.g., system calls) but for debugging Logic Errors the onus is on the developer, who has knowledge of how the program should behave, to identify the source of an error.