Compilation errors invisible when Code Analysis set on TFS2010

I am getting my hands on TFS 2010, and I am starting with trying to set a continuous integration build up. For this purpose I am using the default build template (DefaultTemplate.xml) configured with Code Analysis set as Always.

Everything works fine... except when it does not.开发者_运维知识库 When there is an error in the build (or a test failure), the only error available in the TFS report is the following

Unable to read Code Analysis output report. Make sure that the directory is writable (default is the project output directory).

The original error is reported only when there is no code analysis. When no error, the code analysis reports are correctly output.

Any ideas?

About the "Unable to read Code Analysis output report" error:

• If it happens when compiling in Visual Studio, it could be that the resulting log file path is too long (Ref).
• If it happens when compiling in TFS build, it's because the project contains unneeded elements <CodeAnalysisLogFile> and <CodeAnalysisInputAssembly> (Ref).

In our solution, every project imports a Common.Targets file - I intend to override these and thus avoid the problem for all future projects.

What I expect is the following:

• Code analysis off, no error: Build is fine
• Code analysis off, build error: Workflow does not expect a code analysis file to be generated, original error is displayed, OK.
• Code analysis on, no error: Analysis output is generated, and all goes fine.
• Code analysis on, build error: Due to build error, code analysis is not performed, the ouput file is not generated. However the workflow expects to find an output file, which it does not find and this becomes the primary error logged in the build exception, hiding the original one.

So please inspect the order of items in your build template, to see if this is applicable and change it to make sure the code analysis output is not expected when a build error occurs.

I have built a solution with msbuild in parallel (/m switch) on our CI server and same error occurs (other file lock specific errors as well, like: The process cannot access the file x.y.z because it is being used by another process). Conclusion: Remove /m because it is not safe :-(