在Visual Studio中“将所有警告视为除...之外的错误”

Question

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

有一个选项可以禁止警告，但我们希望它们显示为警告，这样就无法使用。

似乎获得我们想要的行为的唯一方法是在“特定警告”文本框中输入每个C＃警告号的列表，除了我们想要作为警告的两个。

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

有谁知道更好的方法吗？

---

澄清那些没有立即看到为什么这有用的人。想想大多数警告是如何工作的。他们告诉你刚才写的代码中有些东西。修复它们大约需要10秒钟，这样可以保持代码库的清洁。

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

文字“#warning”警告也是独一无二的。我经常想要来检查它，但我不想打破构建。

Answer 1

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

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

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

Answer 2

/ warnaserror / warnaserror-：618

Answer 3

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

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

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

Answer 4

为什么您要继续看到您没有将其视为错误的警告？我很困惑为什么这是可取的 - 要么你修复它们要么你不修复它们。

两个不同的构建/解决方案文件是否有效 - 或者是一个脚本来复制一个然后修改警告/警告级别是合适的。似乎你可能希望编译器的某些执行被发出尖叫声，但是你想要继续执行其他命令。

所以不同的编译器开关似乎是一个很好的方法。您可以使用不同的目标执行此操作 - 一个标记为调试或发布，其他目标则适当标记警告。

Answer 5

我正在使用处理警告作为错误。

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

如果存在某些问题，此指令的存在还允许找出谁接受此警告违规行为（通过版本控制的“责备”行为）。

Answer 6

在 Visual Studio 2022 中，我们有一个新的项目属性 UI，其中包含一个编辑器。

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

这会将以下属性添加到您的项目中：

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

Answer 7

为什么不简单地有一条规则说“谁用其中的任何警告检查代码除了612,1030,1701或1702之外必须进入白板并写一百次'我不会在不允许的情况下签入代码警告再次。'“

Answer 8

编译指示警告（C＃参考）

pragma警告可用于启用或禁用某些警告。

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

Answer 9

在我看来，根本问题实际上是将您的处理警告视为错误的组合，当它们显然不是错误时，以及您明确的允许签入违反此规定的政策。正如你所说，你希望能够继续工作，尽管有警告。你只提到了一些你想要忽略的警告，但是如果团队中的其他人引起了任何其他类型的警告，这会花费你同样长的时间来解决这个问题呢？你不想也不能忽视它吗？

逻辑解决方案是：1）禁止签入代码是否编译（这意味着创建警告的人必须修复它们，因为实际上，它们打破了构建），或2）处理警告作为警告。创建两个构建配置，一个将警告视为错误，可以定期运行以确保代码无警告，另一个仅将其视为警告，并允许您即使其他人引入警告也能工作。