在Visual Studio中“将所有警告视为错误，但……除外”

在Visual Studio中，我可以选择“将警告视为错误”选项，以防止在有任何警告的情况下编译我的代码。我们的团队使用此选项，但我们希望保留两个警告作为警告。

有一个选项可以禁止显示警告，但是我们确实希望它们显示为警告，所以这行不通。

看来，获得所需行为的唯一方法是在“特定警告”文本框中输入每个C＃警告编号的列表，但我们希望将其视为警告的两个除外。

除了维护上的麻烦之外，此方法的最大缺点是一些警告没有数字，因此无法明确引用。例如，“无法解析此引用。无法找到程序集'Data ....'。”

有人知道更好的方法吗？

为那些看不到为什么有用的人澄清。考虑一下大多数警告的工作方式。他们告诉您刚刚编写的代码有些不对劲。修复它们大约需要10秒钟，这使代码库更加整洁。

“过时”警告与此完全不同。有时修复它意味着只使用一个新的方法签名。但是，如果整个类都已过时，并且您的用法分散在成千上万的代码行中，则修复可能需要数周甚至更长的时间。您不希望这么长时间破坏构建，但是您确实希望看到关于它的警告。这不仅仅是一个假设的情况-这发生在我们身上。

文字上的“＃警告”警告也很独特。我经常想签入，但是我不想破坏构建。

您可以WarningsNotAsErrors在项目文件中添加-tag。

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

注意：612和618都是关于过时的警告，不知道有什么区别，但是我正在处理的项目正在报告警告618的过时。

/ warnaserror / warnaserror-：618

或更具体地说，在您的情况下：

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

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

为什么要继续看到不被视为错误的警告？我对为什么这是理想的感到困惑-要么修复它们，要么不修复它们。

可以使用两个不同的构建/解决方案文件-还是可以复制一个脚本然后再修改警告/警告级别的脚本。似乎您可能想让编译器的某些执行变得混乱，而其他一些您想一直保持下去。

因此，不同的编译器开关似乎是一个不错的选择。您可以使用不同的目标来执行此操作-一个标记为debug或release，另一个标记为警告。

我正在将警告视为错误。

在极少数情况下，如果出现一些可以接受的警告（即，引用过时的成员或缺少XML序列化类的文档），则必须使用#pragma disable显式禁止它（并且可以选择提供没有干净代码的原因）作为评论）。

此指令的存在还可以找出（如果有任何疑问）谁接受了此警告违规（通过版本控制的“非议”行为）。

为什么不简单地说一条规则：“凡检入代码中除612、1030、1701或1702以外的任何警告的人都必须进入白板并写下一百次，'我将不会再次检入带有不允许的警告的代码。 '”

编译指示（C＃参考）

编译指示可以用于启用或禁用某些警告。

http://msdn.microsoft.com/zh-cn/library/441722ys(VS.80).aspx

在我看来，根本的问题实际上是您将警告视为错误（如果不是明显的错误）以及您明显允许违反这一规定的入住政策的结合。如您所说，尽管有警告，您仍希望能够继续工作。您仅提到了一些您希望能够忽略的警告，但是如果团队中的其他人引起了其他任何类型的警告，那将花费您同样长的时间来解决？您是否也想忽略它？

逻辑解决方案是：1）如果代码未编译则不允许签入（这意味着创建警告的人将不得不对其进行修复，因为实际上他们破坏了构建），或者2）将警告视为警告。创建两个构建配置，一个将警告视为错误，可以定期运行以确保代码没有警告，而另一个，仅将它们视为警告，即使其他人引入了警告，您也可以工作。