Visual Studio 中的“将所有警告视为错误，除了...”

Posted 2023-02-15

【中文标题】Visual Studio 中的“将所有警告视为错误，除了...”

【英文标题】："Treat all warnings as errors except..." in Visual Studio

【发布时间】：2010-09-20 23:56:05

【问题描述】：

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

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

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

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

有人知道更好的方法吗？

---

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

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

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

【问题讨论】：

你能在你的大数字列表中加入空格吗？它塞满了换行符。

天哪，我讨厌人为制定的复杂规则，通常是为了安抚某些特定人的自我。

我明白他关于过时警告的观点，这不是任意的。

根据我的经验，在你的构建中允许一个警告就像添加第一个异步/等待。很快就会有几十个。在所有设置中，我记得开发人员能够在 VS 的错误列表窗口中看到少于 10 个警告。我敢打赌，一旦你有超过 5 个警告，团队中的绝大多数开发人员将无法发现一个新的 - 在你的设置中，这意味着他们不会发现该方法已过时的警告，这无视发出警告的全部目的:) 你对这个尼尔有什么经验？

@mayu，这是一个难题。很多时候，我看到警告被忽视了很长时间。但最终，要么显示警告，要么什么都不显示。如果您显示警告，至少有人有机会从中学到有用的东西。如果您将大多数警告视为错误，那么剩下的少数可以得到更多关注。

【参考方案1】：

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

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

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

【讨论】：

612和618的区别在于ObsoleteAttribute的注释。不带注释的 ObsoleteAttribute 生成错误 612，带注释的则生成 618。

@MarcoSpatz 没错。然后我们可以将message 为null 的[Obsolete] 成员视为错误，而我们让那些设置了message 的成员仅保留警告。如果ObsoleteAttribute中的error参数设置为true，则会生成CS0619。如果message 是null，这似乎不起作用（但无论如何谁会做[Obsolete(null, true)]？）。

对于 F#，在 Build->Other flags 字段中使用 --warnaserror-:618,1030。此项目选项尚未针对 F# 项目实施。 github.com/Microsoft/visualfsharp/issues/3395

很高兴知道“WarningsNotAsErrors”存在。它应该在项目设置中可用，而无需手动编辑文件。谢谢。

微软真的把这件事搞砸了（11 年后，还没有解决问题！）。项目设置更改<NoWarn>，在大多数情况下效果较差，未能将<WarningsNotAsErrors>放入UI。荣誉。

【参考方案2】：

/warnaserror /warnaserror-:618

【讨论】：

感谢您的意见。尽管它们没有解决 IDE 问题，但它们是迄今为止最有用的 cmets。

你在哪里添加这个？

@checho，这些开关将在调用 msbuild 时添加到命令行中。就我们的目的而言，最佳答案更有帮助，因为我们可以将其烘焙到项目中，而不必修改我们调用 msbuild 的方式。

不适用于 MSBuild 15.9.21+g9802d43bc3：MSBUILD : error MSB1001: Unknown switch. Switch: /warnaserror-:618

【参考方案3】：

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

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

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

【参考方案4】：

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

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

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

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

【讨论】：

德鲁，感谢您告诉我们！很高兴知道终于有一个高度可发现的解决方案。我将其更改为已接受的答案。

这个新 UI 允许我们比在旧页面中更轻松地添加和修改项目属性 UI。您可以在最新的 VS2019 预览版本中试用它（如果您在选项窗口中打开“使用更新的项目属性 UI”功能标志），直到 VS2022 发布。

【参考方案5】：

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

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

所以不同的编译器开关似乎是一个不错的方法。您可以使用不同的目标来执行此操作 - 一个标记为 debug 或 release，其他标记适当地与警告有关。

【讨论】：

大多数警告的发生是因为我的代码中有一个简单的混淆（例如，我声明了一个我不使用的变量）。由于其他人的代码发生更改，经常会发生过时警告。解决这个问题可能需要数周的开发时间。 #warning 是我想要在代码中出现的警告（可能是长期修复）。

换句话说，有警告说我不想破坏我的构建。如果#warning 破坏了构建，那么我永远无法签入。如果 Obsolete 破坏了构建，那么我们依赖的另一个团队可能会在不知不觉中破坏我们团队的构建，只需添加一个过时的属性。

@Neil 我同意你的一些论点，但是删除你不使用的变量并不需要太多时间并且你肯定想知道另一个团队制作的过时的东西。

@mayu，另一个团队（无论是在同一公司内部还是外部）可能合法地想要传达某个类、方法和其他组件在一段时间内被逐步淘汰的信息。添加属性是向库的使用者发出这一信号的好方法。我不认为这样做很麻烦。事实上，尽早添加属性是确保其他人了解未来变化的好方法。

微软有时会淘汰一些东西。

【参考方案6】：

我将警告视为错误。

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

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

【讨论】：

我也用这个，虽然它不能解决我描述中提到的问题。我希望某些警告被视为警告，而不是隐藏。

【参考方案7】：

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

【讨论】：

祝你好运……将警告视为错误是提高整体代码质量的非常重要的一步并且它将迫使开发人员实际修复他们的代码！所有的冰雹自动化，体力劳动是所以 20世纪：ish！

@AndreasMagnusson 如果只有没有警告实际上确保了代码的质量..

@user2864740：同意，没有灵丹妙药。但是，在有用的东西不是灵丹妙药的前提下拒绝它是一个非常普遍的谬论。

【参考方案8】：

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

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

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

【参考方案9】：

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

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

【讨论】：

使用选定的答案，很容易添加到被视为警告的警告列表中。这比您提出的任何一个解决方案都好得多。警告显然不是错误，但将大多数警告视为错误意味着代码将永远不会与这些警告一起签入。