“将所有警告视为错误，除了...”在 VisualStudio 中

在 VisualStudio 中，我可以选择“将警告视为错误”选项，以防止代码在有任何警告时进行编译。我们的团队使用这个选项，但是有两个警告我们希望保留为警告。

有一个选项可以禁止显示警告，但是我们确实希望它们以警告的形式出现，所以这样做不起作用。

似乎获得我们想要的行为的唯一方法是在“具体警告”文本框中输入每个 C # 警告编号的列表，除了我们想要作为警告处理的两个以外。

除了维护方面的麻烦之外，这种方法的最大缺点是少数警告没有数字，因此不能显式引用它们。例如，“无法解析此引用。无法定位程序集‘数据... ...’”

有人知道更好的办法吗？

对于那些没有立即看到为什么这是有用的澄清。考虑大多数警告是如何工作的。他们告诉你你刚写的代码有点不对劲。修复它们大约需要10秒钟，这使得代码库更干净。

“过时”警告与此非常不同。有时候，修复它意味着只消耗一个新的方法签名。但是，如果一个完整的类已经过时，并且它的使用分散在数十万行代码中，那么可能需要几周或更长时间才能修复。您不希望构建被破坏的时间太长，但是您肯定希望看到关于它的警告。这不仅仅是一个假设的案例——这已经发生在我们身上了。

字面上的“ # 警告”警告也是唯一的。我经常用 想要检入，但我不想破坏构建。

25688 次浏览
小开

为什么您希望不断看到未被视为错误的警告？我不明白为什么这是可取的——要么你修复它们，要么你不修复它们。

两个不同的构建/解决方案文件是否可以工作——或者一个脚本复制一个，然后修改警告/警告级别是否合适。似乎您希望某些编译器的执行发出“咯吱”声，但是其他的执行则希望继续执行。

因此，不同的编译器开关似乎是一个不错的选择。您可以对不同的目标进行此操作——一个标记为 debug 或 release，另一个标记为与警告相适应。

小开

在我看来，根本问题实际上是你将警告视为错误(当它们显然不是错误的时候) ，以及允许违反这一点的签入的明显政策的结合。正如您所说，您希望能够不顾警告继续工作。您只提到了几个您希望能够忽略的警告，但是如果团队中的其他人引起了任何其他类型的警告，这将花费您同样长的时间来修复呢？你难道不想忽略这一点吗？

逻辑上的解决方案是: 1)如果代码没有编译就不允许签入(这意味着那些创建警告的人必须修复它们，因为实际上，他们破坏了构建) ，或者2)将警告视为警告。创建两个构建配置，一个将警告视为错误，可以定期运行以确保代码没有警告，另一个只将它们视为警告，并允许您在其他人引入警告的情况下工作。

小开

杂注警告(C # 参考)

杂注警告可用于启用或禁用某些警告。

Http://msdn.microsoft.com/en-us/library/441722ys(vs.80).aspx

小开

/warnaserror/warnaserror-: 618

小开

或者更具体地说，你的情况是:

/warnaserror/warnaserror-: 612,1030,1701,1702

除了逗号分隔的列表中的警告之外，这应该将所有警告都视为错误

小开

可以在项目文件中添加 WarningsNotAsErrors标记。

<PropertyGroup>
...
...
<WarningsNotAsErrors>618,1030,1701,1702</WarningsNotAsErrors>
</PropertyGroup>

注意: 612和 618都是关于过时的警告，不知道区别，但我的项目工作是报告过时的警告618。

小开

我将警告视为错误。

在极少数情况下，当一些可以接受的警告出现时(比如引用过时的成员，或者缺少 XML 序列化类的文档) ，那么它必须是显式的 禁用 # 杂注(可选的理由是没有一个干净的代码可以作为注释一起提供)。

这个指令的存在也允许查找，谁接受这个警告违反(通过“指责”动作的版本控制)万一有一些问题。

小开

为什么不简单地制定一个规则: “除了612、1030、1701或1702以外，任何人在代码中检入任何警告，都必须在白板上写上一百遍‘我不会再检入不允许的警告。'"

小开
最佳答案

在 VisualStudio2022中，我们有一个新的 ProjectProperties 用户界面，其中包括用于此的编辑器。

在 构建 | 错误和警告下，如果将 将警告视为错误设置为 全部，则会出现另一个属性，允许您免除将特定警告视为错误的情况:

enter image description here

这将向项目添加以下属性:

<WarningsNotAsErrors>618,1030,1701,1702</WarningsNotAsErrors>

提交答案