Category: FxCop/Code Analysis

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.

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.

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”.

Yeah. That’s bad.. We are extensively using async/await in most of our projects. We have a guideline for developers to follow the code analysis with our own custom ruleset. We even run CA on CI (Yes! Initially, we were using FxCop on CI but we found one blocking issue that makes us to stop using FxCop on CI). but now, we found that CA is not able to analyze the async methods in both Visual Studio 2012 and Visual Studio 2013 RC.

The only workaround that I am using now is that I removed the FxCop from CI and use Code Analysis instead. But you might not want to run the code analysis on every build on developer machine so you can create another configuration setting (maybe CI) and enable the code analysis for that setting or you can use the code analysis switch on MSBUILD.

———-

No. It’s not the problem and solution post. This post is about the issue that we are not able to solve until now. We integrated the standalone version of FxCop with our custom ruleset to make sure all of our projects are following our guideline on our CI (Continuous Integration) server.We have a .NET 4.5 project that is using an open source dependency injection framework called Autofac that has the dependency on the Portable Class library. When we run FxCop for that project, we got the error below.

Error Message

Microsoft.FxCop.Sdk.FxCopException: The indirectly-referenced Silverlight assembly ‘System.Core, Version=2.0.5.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e, Retargetable=Yes’ could not be found. This assembly is not required for analysis, however, analysis results could be incomplete. Silverlight reference assemblies should be specified with the ‘/reference’ switch. This assembly was referenced by: {0}\bin\Autofac.dll.

I am still not able to find the solution yet but what I found is that a lot of people are having the same problem and asking for new version of FxCop for .NET 4.5.