当前位置：文江博客话题详情

如何根据 FXCop 警告使 TFS 构建失败

发布于 2024-09-15 08:56:22 字数 145 浏览 8 评论 0原文

我们目前使用 TFS 2008 进行源代码控制和持续集成。

我们使用 FXCop 来检查性能和安全警告。架构师或高级开发人员在冲刺结束或交付之前运行 FX Cop。

我们希望它作为 CI 的一部分运行，如果出现警告则构建失败，最好的方法是什么？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

平生欢 2024-09-22 08:56:41

假设您通过 MSBuild 和常规项目/解决方案进行构建，则可以将 FXCop 配置为作为每个构建（客户端和服务器）的一部分运行。在项目的属性对话框中，查看“代码分析”选项卡。请注意，这可以为调试和发布版本单独设置，因此您可以将它们设置为发布版本的错误（如果这能让开发人员的生活更轻松）。

这些 FXCop 设置允许您定义违规在构建中显示为错误而不是警告。您可能还希望启用 TFS 策略，该策略要求在签入有效之前使用一组定义的规则运行代码分析 - 这将通过强制开发人员在签入之前修复违规行为来节省一些红色构建。

我确实建议打开所有这些东西 - 如果您的目标是达到这种质量水平（这不是坏主意），那么最好尽可能多地进行预登记。

回复收藏 0 原文

趴在窗边数星星i 2024-09-22 08:56:34

我一直在做类似的事情。尽管这个问题有点老了，但我希望它能对你有所帮助。

我像大多数人一样开始 - 通过创建一个调用 FxCopCmd 的构建后事件。

就我而言，我只需要一小部分代码、一些内置规则以及一些自定义规则（在 .dll 中），

为此我使用了 .fxcop 项目文件 - 按照我的方式配置它通过 GUI 需要，然后在构建后事件中将 FxCopCmd 指向项目文件。

在大多数情况下，它运作良好，但违规行为仅作为警告出现。 “将警告视为错误”选项似乎不适用于此，因此我不得不提出不同的解决方案。

最终最适合我的是基于我偶然发现的一篇博客文章。

我修改了项目文件以添加两个新事件。

我有一些 FxCop 的额外参数和内容，但其要点是：

   1: <PropertyGroup>
   2:   <FxCopResults>$(ProjectDir)obj\$(Configuration)\FxCopResults.xml</FxCopResults>
   3:   <PostBuildEvent>"%25ProgramFiles%25\Microsoft FxCop 10.0\FxCopCmd.exe" /file:"$(TargetPath)" /console /out:"$(ProjectDir)obj\$(ConfigurationName)\FxCopResults.xml"</PostBuildEvent>
   4: </PropertyGroup>
   5: <Target Name="BeforeBuild">
   6:   <Delete Files="$(FxCopResults)" ContinueOnError="true" />
   7: </Target>
   8: <Target Name="AfterBuild">
   9:   <Error Text="One or more FxCop warnings occurred." Condition="Exists('$(FxCopResults)')" />
  10: </Target>

一般流程如下：

（构建过程已触发）
在构建开始之前，之前的 FxCop 结果（如果它们存在）被清除。
触发预构建事件
（构建开始）
触发构建后事件（运行 FxCopCmd）
构建后完成后，如果有 FxCop 结果，则会引发错误。
（构建过程已完成）

现在，如果 FxCop 分析生成（例如）4 个规则违规，您的构建将生成 4 个警告和 1 个错误。

我希望这有帮助。

I've been working on something similar. Even though this question is a bit old, I'm hoping it will help you.

I started out like most -- by making a post-build event that calls FxCopCmd.

In my case, I wanted just a small subset of the code, some of the built-in rules, and also some custom rules (in a .dll)

I used an .fxcop project file for this -- configuring it all just how I wanted via the GUI and then pointing FxCopCmd to the project file in the post-build event.

For the most part, it worked great, but the rule violations came up only as warnings. The "Treat warnings as errors" option doesn't seem to apply to this, so I had to come up with a different solution.

What ultimately worked best for me was based on a blog post I stumbled upon.

I modified the project file to add in two new events.

I have a few extra parameters and stuff for FxCop, but the gist of it is:

   1: <PropertyGroup>
   2:   <FxCopResults>$(ProjectDir)obj\$(Configuration)\FxCopResults.xml</FxCopResults>
   3:   <PostBuildEvent>"%25ProgramFiles%25\Microsoft FxCop 10.0\FxCopCmd.exe" /file:"$(TargetPath)" /console /out:"$(ProjectDir)obj\$(ConfigurationName)\FxCopResults.xml"</PostBuildEvent>
   4: </PropertyGroup>
   5: <Target Name="BeforeBuild">
   6:   <Delete Files="$(FxCopResults)" ContinueOnError="true" />
   7: </Target>
   8: <Target Name="AfterBuild">
   9:   <Error Text="One or more FxCop warnings occurred." Condition="Exists('$(FxCopResults)')" />
  10: </Target>

The general flow is like this:

(BUILD PROCESS IS TRIGGERED)
Before a build starts, the previous FxCop results (if they exist) are cleared out.
Pre-Build Event is triggered
(BUILD BEGINS)
Post-Build Event is triggered (which runs FxCopCmd)
After the Post-Build finishes, if there are FxCop results, an error is raised.
(BUILD PROCESS IS COMPLETE)

Now, if the FxCop analysis generated -- for example -- 4 rule violations, your build would generate 4 warnings and 1 error.

I hope this helps.

回复收藏 0 原文