For the past week or so, I've been performing last-minute documentation tasks at the day job in preparation for the impending maternity leave. If you've been reading this blog because of my FxCop posts, then you might be interested in my latest post on the FinRad blog , which covers the statistics collection tool that we developed internally to help us track our FxCop backlog cleanup efforts . A copy of the tool is also available on CodePlex if you would like to try it out for yourself.

So... Umm... It's been a while. A little over six months, to be specific. That would be three months of unrelenting nausea and surprisingly heavy fatigue, followed by three months of desperately trying to catch up on all the "real world" stuff that didn't get done during those first three months. But now it's winter, and I'm looking forward to three months of not skiing, so there should be plenty of time for 'putering (at least once the pesky December holiday season

We've got a rather large VB code base at FinRad , at least some of which we would like to migrate to C# in the nearish future. Because of this, we have created several custom rules that are intended to detect issues in VB code that would cause problems when migrating the code to C#. However, while attempting to assign categories for those custom rules, we quickly realized that each of them had merits besides portability of the code base, and that we wanted our assemblies to abide by these rules

If you're considering tackling an FxCop backlog , you're going to need a few tools. Obviously, the most important of these is FxCop itself, but that still leaves you with a potential choice to make between stand-alone FxCop and Visual Studio Static Analysis. If your target code base is built against .NET 1.1 or if you're not willing/able to shell out for Team Edition for Software Developers or Team Suite, the decision is pretty trivial. However, what if all your developers already have

Off on a bit of a tangent this morning... I have a bit of a love/hate relationship with the Visual Studio start page. I do find it useful enough when I first open VStudio. However, once I start working on anything, the mere presence of the start page tab in the IDE main window is really, really irritating to me for some reason. Of course, given that even one little using directive out of place also drives me to distraction, this probably isn't too surprising. At any rate, the other day, I decided

I skipped ahead a while back with my post on the exceptions theme , and it's time to get back on track with stuff that would usually precede that rather involved topic during an FxCop backlog cleanup project. The good news with the disposition and finalization topic is that its scope is quite a bit narrower than the exceptions topic. The bad news is that you'll probably see almost as many preconceptions regarding how it works, particularly if you have quite a few developers who are accustomed

With profound apologies to VB lovers, there are a few features of the VB compiler that occasionally make me want to start drinking at a very early hour of the day. Perhaps the most troublesome of these is its failure to start screaming bloody murder upon detection of namespaces that differ only by case, even while compiling an assembly that is marked as CLS-compliant. VB 2005 is at least kind enough to conserve the casing from the source code. However, VB 2003 seems to more or less randomly pick

Since I started monitoring traffic on this blog a little more closely about a week ago, I had the unexpected surprise that the posts on HTML encoding and server vs. client cultures were getting a lot more hits than I expected. I had been planning on starting a series of "how to" posts on those topics this weekend, but that was before David Kean from the FxCop team was kind enough to direct a bunch of folks my way with a post about my recent FxCop posts . Since it would seem that I've

If you've decided to try to tackle an FxCop violation backlog , one of the first issues you're going to face is deciding which rules to activate when. Here are some general guidelines... Starting out When you first begin the backlog clean-up process, you're going to need to introduce the FxCop tool to your team (assuming, of course, that you're not already using FxCop for new projects). In order to focus on mastering the tool and the cleanup process before diving into "difficult"

Surprise! (not the good kind) If you use FxCop or Visual Studio Static Analysis and haven't yet started playing with Orcas, you may be in for a bit of an unpleasant surprise. While the code analysis team is doing all sorts of interesting things for Orcas , one somewhat less desirable change you probably haven't heard about yet is removal of the control flow engine and, consequently, the following rules which depend upon it: Category Rule Design ValidateArgumentsOfPublicMethods Globalization