Short version
The old version IL-based FxCop/CA are dead but the new version of CA that based on source-Code instead of IL will be in VS “14”. (You can scroll down and see the reply from Alex Turner, the owner for Diagnostics in managed languages. )
Long version
Yes, I was a huge fan of FxCop/Code Analysis. I forced encouraged everyone in my team to make FxCop/CA happy for every single line of code before they commit. FxCop/CA does help to make sure your code is still following Framework Design Guidelines without assigning some experts to do the manual code review for every commits.
Note: If you are not familiar with FxCop/CA then you can read about them in the following links (FxCop, Code Analysis and FxCop Vs. Code Analysis)
We all know that Microsoft has released a few versions of .NET framework. When was FxCop’s last release? I reported the following issues that we have with FxCop/CA but I didn’t see those issues are being addressed.
- Bug – Code Analysis doesn’t work well with async methods even in Visual Studio 2013
- (Unsolved) FxCop + Portable Library
- Tip: FxCop issue with System.Net.Http
The worst part is that some teams (e.g. MVC/Web API team) from Microsoft are not even following the FxCop’s rules. I posted this questions “Why a fresh new MVC project couldn’t pass the Code Analysis? One-Microsoft” in MSDN forum as well.
I am the one who is encouraging the team to follow FxCop in company but I wasn’t sure why the issues that have been reported a while back are still not being addressed. I wasn’t even sure whether Microsoft is still maintaining the FxCop or not so I tried to reach out to Microsoft team internally and luckily, I got the answer.
Here is the unedited reply from Alex Turner, the owner for Diagnostics in managed languages. I am sharing his email with everyone (including my teams) with his permissions.
Hi Michael,
FxCop has indeed been dormant for a while, and it’s certainly become stale in the face of new C# language features like async. My favorite instance of that is the cyclomatic complexity rule – FxCop will complain that an empty async method has too branches for you to easily maintain, even when it contains no code J
This is all due to FxCop analyzing IL rather than source. That worked great in the C# 1.0/2.0 days when the code you wrote mapped almost directly to IL – rules could look at that IL and work out what the source was. However, heavier transforms like LINQ and async get you too far from the code that was written to give good guidance on anything except method/type naming and IL-level performance tweaks. In the face of such decaying rules, it’s unfortunate but not surprising to me that other Microsoft teams are skipping the dance required to stay FxCop-clean.
For VS “14”, we’re investing heavily in source-based code analysis, built using Roslyn. This not only gives back the fidelity we’ve been missing in async methods and other high-level constructs – it also lets us surface code analysis issues live as you’re typing, even before your code fully builds, since we’re operating on the same syntax trees and symbols that IntelliSense uses. We’re also surfacing a supported API for plugging such rules into the compiler as you build, so that API authors and other third parties finally have a supported way to build such analysis, rather than hacking it into FxCop.
As Christoph pointed out, we’re proving out our new Roslyn-based diagnostics by reimplementing the high-value, low-false-positive FxCop rules using Roslyn. We haven’t yet decided when to pull the switch and officially swap out the IL-based FxCop rules for rules built on Roslyn, but the new live analysis engine will be built into the C#/VB compilers in VS “14” (it’s already in the CTP). At a minimum, we’ll ship this set of rules online, as an opt-in package you can use instead of the built-in VS support.
Alex Turner
Senior Program Manager
Managed Languages
—————–
The conclusion is that the old version IL-based FxCop/CA are dead but the new version that based on source-code analysis instead of IL will be in VS “14”.
