3742

I’ve had publication of a little FxCop rule-building toolkit on my todo list for at least the past three years. I finally got the beastie out the door yesterday evening… The Bordecal tools for FxCop include two main pieces: A rule development framework with two main pieces: A testing framework for custom rules, and Rule base classes that allow configuration via code rather than an embedded XML file. A set of custom rules. The testing framework is probably the single most important part. For those of you who are already familiar with Roy Osherove’s FxCopUnit, it is important to understand … Continue reading Introducing the Bordecal tools for FxCop

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.

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 regardless of whether or not they might eventually be ported … Continue reading Some FxCop rules for VB

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 Visual Studio 2005 editions that include static analysis? You’ve paid for it, so your first instinct will probably … Continue reading FxCop backlog tools: FxCop

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 to deterministic finalization. As with the exceptions topic, it’s probably a pretty good idea … Continue reading FxCop backlog themes: Disposition and finalization

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 one case version and apply it throughout an assembly, and that … Continue reading FxCop is case-sensitive. VB is annoying.

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 now got quite a few new subscribers … Continue reading FxCop backlog themes: Exceptions

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” rules, you’ll want to pick a few rules to activate that meet the following criteria: The rule itself … Continue reading FxCop backlogs: Some rules for rule activation

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 DoNotPassLiteralsAsLocalizedParameters Performance AvoidUnnecessaryStringCreation DoNotCallPropertiesThatCloneValuesInLoops DoNotConcatenateStringsInsideLoops Reliability DisposeObjectsBeforeLosingScope Security ReviewSqlQueriesForSecurityVulnerabilities Usage AttributeStringLiteralsShouldParseCorrectly DisposeMethodsShouldCallBaseClassDispose DoNotDisposeObjectsMultipleTimes LiteralsShouldBeSpelledCorrectly ProvideCorrectArgumentsToFormattingMethods The reasons given for removing the engine … Continue reading Control flow engine, 200?-2007, RIP

A few months ago, I gave a presentation on using FxCop at the Montreal Visual Studio Users Group. The material was divided into two main topics: (a) the mechanics of using FxCop and (b) integrating FxCop use into a development process. During the first part of the talk, some members of the peanut gallery kept piping up with questions about what one can do to handle the huge number of FxCop rule violations that an existing code base will have when one first runs FxCop against it. Lucky for me, most of the second part of the talk covered exactly … Continue reading FxCop and the big, bad backlog