FxCop (Team System) MSDN Chat Roundup

Update: The transcript for this chat can be found here. 

Once again we had another really successful chat with over 320 customers attending. Thank you to all that attended, you asked some really good questions.

The following is a list of questions/answers that were asked about FxCop/Managed Code Analysis:

Michael Fanning [MS] (Expert):
Q: Is Prefast within the static code analysis team?
A: Yes, FxCop and PREfast are owned by this team.

Michael Fanning [MS] (Expert):
Q: Any plans on providing a similar API for C++ Code Analysis? (AKA Prefast?)
A: I apologize, I misunderstood your original question. The analysis functionality for both managed and native is reasonably complete. The managed custom rules API is not yet entirely stable. We continue to reduce the API to a set that is constrained to a binary view (our original API also included constructs relevant to a source-code view). I believe we will also be making ongoing changes to string representations for metadata entities. On the native side, our tool integrates with the actual language front-end, which, of course, is subject to ongoing development. This complicates shipping a stable analysis API. We are looking at moving to a stable abstraction that we can document but this won't occur in the Orcas time-frame.

Brian Harry (Expert): Q: Can we disable code analysis policies on some part of the source control structure?
A: Not in the currently shipping product.  We are currently working on a power tool for policies that will allow you to scope power tool to folders in the source tree.

Michael Fanning [MS] (Expert):
Q: How can we make Code analysis setting migration works, to apply TeamServer code analysis rules apply on all our projects?
A: Currently, migration occurs as a per solution gesture. We are looking at providing a power toy that would permit scripting this process.

TanPhan_MS (Expert): Q: Is it possible making check in impossible if code analysis have not been run on a project/solution (remove override)  IN THE NEXT VERSION?
A: We'll file this one as a feature request.

Michael Fanning [MS] (Expert):
Q: Is it possible making check in impossible if code analysis have not been run on a project/solution (remove override) ?
A: We discussed the possibility of making this an administrator setting. Developers can suppress any code analysis result, however, so the process is already implicitly on something of an honor system. ie, even if we made it impossible to override the literal policy failure, any developer could simply suppress violations in source code in order to satisfy policy. Based on that, we think it would be more valuable to build better guidance and some auditing features into the tool (so that results suppressions can easily be reviewed).

Brian Harry (Expert): Q: The fact that a developer can override policy during check-in has confused many users.  Any comments on why this is allowed?
A: The reason we allow it is that there are sometimes scenarios where it is necessary to get a check in done in spite of policy errors.  Our thinking was that as long as it is auditable - easy to tell who over rode policies and why that it was sufficient.  We've gotten feedback that some customers would like tighter control than that.  We will look at adding it in a future version.

Michael Fanning [MS] (Expert):
Q: Is there anything in Code Analysis that reports on duplicate code? And metrics (LOCs, cyclomatic complexity, classes, methods, % comments, etc)?
A: We currently do not have any functionality that flags duplicate code but we are actively investigating this possibility. As far as code metrics are concerned, the current version of the tool does flag code that exceeds a standard threshold for cyclomatic complexity. We also have analysis that looks at inheritance depth. We will be augmenting this functionality with a broader range of metrics (and configurability) in the future. I can't say yet what exactly will make it into Orcas; perhaps we'll be able to comment on this in a future chat. Be sure to keep participating. 8)

Michael Fanning [MS] (Expert):
Q: When you select migrate code analysis policies by right clicking on the solution in VS, rules are not always apply correctly; some are not disabled correctly are not change from error to warning etc...
A: When you migrate policy settings, VSTS will not snap to an exact copy of those settings. Instead, we elevate the local settings where they do not meet the server standard. As an example, if you have a rule that is marked locally as an error, but marked on the server as a warning, the rule will still be marked as an error after migration. This permits users to maintain a more aggressive standard for development. Our power toy will support the ability to exactly duplicate the server settings, if that works for your scenario.

Michael Fanning [MS] (Expert):
Q: Any changes coming in the way Code Analysis rules are migrated to a solution from a team project?  For example any options that will allow you to turn CA rules on as well as turn them off?  Currently the migration will only turn rules on, not off.
A: I covered this a bit in an earlier reply. The current policy settings migration enforces a 'meet or exceed' standard. That is, if a local settings meets or exceeds the server setting, it will be preserved locally. As mentioned, we have a power toy in development that will permit more flexibility in migration. We will look at making this change in the product but it's not yet clear whether will do so.

Michael Fanning [MS] (Expert):
Q: Has there been any improvements in the reduction of Code Analysis suppressions being forced into GlobalSuppressions.*?
A: If a code analysis violation is being incorrectly forced into a global suppression, that's most likely a defect in the product. Currently, we always apply the suppression directly to the target, assuming we can locate it. Since there's no source representation for a resource, as one example, a suppression against this kind of metadata will always end up being emitted to the global file. We have identified some issues in VS2005 (mostly in the area of generic methods) where we were not correctly locating the analysis target. These have been fixed. We have also added a new feature (the opposite of what you've mentioned) which allows users to explicitly redirect suppressions to a global file. This is useful for base-lining a set of analysis results that will be addressed at a future date. To wrap up, if you have an example of a suppression that is being emitted globally where a suitable local target exists, let us know. There might be a lingering issue we can address in Orcas.

Michael Fanning [MS] (Expert):
Q: Speaking of code metrics: any plans on making this configurable?  e.g. only warn when cyclomatic complexity is higher than instead of the default of 25?  Same for critical error, error, critical warning, information, and recommended cyclomatic values...
A: We have discussed this. Making custom rules generally configurable within VS would be a significant change to our extensibility model, though, and this work will generally (for good reasons, I think) follow behind our delivery of a final metadata API. We are looking at creating a specialized unit test type that will permit a configurable analysis (where all available code metrics thresholds can be changed). It's not clear whether this will make it into the final release but I think it's very likely we can ship this as a power toy if it doesn't make it.

This entire report with be posted on https://msdn.microsoft.com/chats/transcripts/vstudio/default.aspx in the next couple of weeks.

If you missed this chat, don't worry, we will have upcoming chats in the future, keep a watch out on https://msdn.microsoft.com/chats/.