Welcome back! My name is Tim Sneath, and I work in the Developer & Platform group in Microsoft UK. In the last issue of the new MSDN Flash, we looked at a number of helpful third-party utilities that can help you get the most out of the .NET Framework. One of the tools that I mentioned then was FxCop, a utility from the .NET Framework team that helps improve the quality of your .NET code, and I wanted to drill a little deeper into this area.
As software engineers, we are not simply interested in whether the code we write executes successfully. For instance, it’s important to write code that is both scalable and secure, easy to maintain and modify, portable to other languages and cultures, and can be readily reused by other developers. Seminal books such as Code Complete and The Art of Programming have demonstrated techniques that can improve code quality, and new advances continue to be made in this area.
Since work began on the 3800+ types that form the .NET Framework libraries, we’ve been working to internally codify some of the rules that can help improve the quality of .NET code. The result is the .NET Framework Design Guidelines, a comprehensive document based on our own experiences of code that causes problems in certain situations. For example, if you use unmanaged resources from your code, it’s important to implement the IDisposable interface so those resources can be deallocated cleanly. There are over 200 such rules today, and the guidelines continue to evolve based on experience and feedback. Brad Abrams is one of the leaders of this effort, and his blog lists proposed changes and provides a mechanism for others to provide feedback.
However, it’s often hard to verify best practice across a large-scale multi-million line enterprise system with hundreds of rules to enforce. One tool that helps here is FxCop, a free utility that checks .NET assemblies against the design guidelines. I’m amazed how many people still don’t know about this tool: everyone I’ve shown it to immediately wants to use it against their own projects to spot some of the weaknesses in their own code before someone else does!
To use FxCop, you point the tool at your assembly and any dependencies. It then analyses the assembly and provides a list of warnings. Some will be real issues that you’ll want to fix, and others can be safely ignored (for example, some rules are only relevant for COM interoperability). You can exclude certain rules from a particular project and also add custom rules using the supplied SDK. FxCop is now a mandatory element of the build process in most of the development teams at Microsoft, and teams must show that their code complies with the guidelines or at least justify any exceptions for their code to be accepted.
The next major upgrade to FxCop (1.30) is currently in internal beta testing and should be released shortly. This new version adds the ability to examine assemblies without locking the file, which saves you from having to shut it down in order to rebuild a project. Tools such as FxCop will not guarantee code quality: they only concern themselves with a small part of the overall picture, but they are nevertheless a valuable addition.