131

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

有一个禁止警告的选项，但我们确实希望它们显示为警告，所以这不起作用。

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

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

有谁知道更好的方法来做到这一点？

为那些没有立即明白为什么这是有用的人澄清。想想大多数警告是如何工作的。他们告诉你，你刚写的代码有些不对劲。修复它们大约需要 10 秒，这样可以保持代码库更干净。

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

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

4

9 回答 9

168

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

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

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

于 2009-01-22T05:52:49.140 回答
14

/warnaserror /warnaserror-:618

于 2008-12-19T08:51:03.000 回答
4

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

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

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

于 2008-12-19T08:53:32.293 回答
2

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

正在构建 | Errors and Warnings如果将Treat warnings as errors设置为All，则会出现另一个属性，允许您免除特定警告被视为错误：

在此处输入图像描述

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

<WarningsNotAsErrors>618,1030,1701,1702</WarningsNotAsErrors>
于 2021-05-15T01:01:15.920 回答
1

为什么您希望不断看到您没有将其视为错误的警告？我对为什么这是可取的感到困惑-要么修复它们，要么不修复它们。

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

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

于 2008-11-06T02:21:25.850 回答
1

我正在使用将警告视为错误。

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

如果有一些问题，该指令的存在还允许找出谁接受了这个警告违规（通过版本控制的“责备”操作）。

于 2009-01-22T06:31:36.970 回答
0

为什么不简单地制定一条规则：“任何签入除 612、1030、1701 或 1702 之外的任何警告的代码的人都必须到白板上写一百次‘我不会再签入带有不允许警告的代码。 '"

于 2009-09-30T16:45:46.437 回答
-2

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

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

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

于 2008-11-24T17:42:31.687 回答
-4

在我看来，根本问题实际上是您将警告视为错误的组合，当它们显然不是时，以及您允许签入的明显政策违反了这一点。正如您所说，您希望能够在收到警告的情况下继续工作。您只提到了一些您希望能够忽略的警告，但是如果团队中的其他人引起了任何其他类型的警告，而这需要您同样长的时间来修复怎么办？难道你不想也能忽略它吗？

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

于 2008-11-10T18:22:31.837 回答