Q) Looks nice in the IDE, but how do I integrate this into my build process?
A) By cunningly enforcing rules at compile time.
Q) Interesting, tell me more. (Not really a question, I know).
A) Go to the project properties and select ‘Code Analysis’. By choosing ‘All configurations’, then enabling (not set by default) Code Analysis and (here’s the cunning bit), set each rule status set to (compile time) ‘Error’ i.e. code will not compile if a rule is broken.
Q) What if I want to turn off a rule?
A) In the properties, you can enable or disable an individual rule or a whole rule set. Alternatively, if you right click on the compile time error in the error list, you can select ‘Suppress Message’. This generates a file in the project called ‘GlobalSuppressions.cs’ which contains assembly attributes for individual rules.
Q) Will it affect my build environment?
A) If you’re calling MSBuild on the command line, you have to set the FXCOPDIR environment variable (see next Q)
Q) So I still need to install FxCop?
A) Not if you have Visual Studio Team Edition for Testers as FxCop is bundled and can be found here (default directory): C:\Program Files\Microsoft Visual Studio 8\Team Tools\Static Analysis Tools\FxCop
Q) Is there any way to force code analysis or check that it’ being run in the build?
A) Code analysis isn’t set by default, so unless you wanted to create a project template with it set you couldn’t make sure it’s enabled on every new project created. You could check the csproj file to make sure it’s enabled using xPath or otherwise (/Project/ProjectGroup/RunCodeAnalysis = true) or check the MSBuild results in the build report.
Q) How can these rules be shared by the team ... are the rules that are turned off saved into the project/solution file?
A)The rules are embedded into the project file (yes, you have to set the rules for each project) including turned off and suppressed rules via the GlobalSuppression.cs file within the project at the root of the project.
No comments:
Post a Comment