C# Visual Studio 中的“将所有警告视为错误，除了...”
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/267168/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
"Treat all warnings as errors except..." in Visual Studio
提问by Neil
In Visual Studio, I can select the "Treat warnings as errors" option to prevent my code from compiling if there are any warnings. Our team uses this option, but there are two warnings we would like to keep as warnings.
在 Visual Studio 中，如果有任何警告，我可以选择“将警告视为错误”选项以防止我的代码编译。我们的团队使用此选项，但我们希望保留两个警告作为警告。
There is an option to suppress warnings, but we DO want them to show up as warnings, so that won't work.
有一个选项可以抑制警告，但我们确实希望它们显示为警告，因此这是行不通的。
It appears that the only way to get the behavior we want is to enter a list of every C# warning number into the "Specific warnings" text box, except for the two we want treated as warnings.
似乎获得我们想要的行为的唯一方法是在“特定警告”文本框中输入每个 C# 警告编号的列表，除了我们希望将其视为警告的两个。
Besides the maintenance headache, the biggest disadvantage to this approach is that a few warnings do not have numbers, so they can't be referenced explicitly. For example, "Could not resolve this reference. Could not locate assembly 'Data....'"
除了维护方面的麻烦之外，这种方法的最大缺点是一些警告没有数字，因此无法明确引用它们。例如，“无法解析此引用。无法找到程序集‘数据....’”
Does anyone know of a better way to do this?
有谁知道更好的方法来做到这一点？
Clarifying for those who don't see immediately why this is useful. Think about how most warnings work. They tell you something is a little off in the code you just wrote. It takes about 10 seconds to fix them, and that keeps the code base cleaner.
为那些没有立即明白为什么这很有用的人澄清。想想大多数警告是如何工作的。他们告诉你，你刚写的代码有些不对劲。修复它们大约需要 10 秒钟，这使代码库更干净。
The "Obsolete" warning is very different from this. Sometimes fixing it means just consuming a new method signature. But if an entire class is obsolete, and you have usage of it scattered through hundreds of thousands of lines of code, it could take weeks or more to fix. You don't want the build to be broken for that long, but you definitely DO want to see a warning about it. This isn't just a hypothetical case--this has happened to us.
“过时”警告与此非常不同。有时修复它意味着只需要使用一个新的方法签名。但是，如果整个类都已过时，并且您的用法分散在数十万行代码中，则可能需要数周或更长时间才能修复。您不希望构建被破坏那么长时间，但您绝对希望看到有关它的警告。这不仅仅是一个假设的案例——这已经发生在我们身上。
Literal "#warning" warnings are also unique. I often wantto check it in, but I don't want to break the build.
文字“#warning”警告也是独一无二的。我经常想检查它，但我不想破坏构建。
采纳答案by SvenL
You can add a WarningsNotAsErrors-tag in the project file.
您可以WarningsNotAsErrors在项目文件中添加-tag。
<PropertyGroup>
...
...
<WarningsNotAsErrors>618,1030,1701,1702</WarningsNotAsErrors>
</PropertyGroup>
Note: 612and 618are both warnings about Obsolete, don't know the difference but the project i'm working on is reporting Obsolete with warning 618.
注意：612和618都是关于过时的警告，不知道有什么区别，但我正在处理的项目正在报告过时，警告为 618。
回答by Tim
Why do you want to keep seeing warnings that you are not treating as errors? I am confused about why this is desirable - either you fix them or you don't.
为什么您希望继续看到您未将其视为错误的警告？我很困惑为什么这是可取的 - 你要么修复它们，要么不修复。
Would two different build/solution files work - or a script to copy one and then so modify the warnings/warning level be suitable. It seems that perhaps you want some executions of the compiler to squawk, but others you want to keep going.
两个不同的构建/解决方案文件是否有效 - 或者复制一个脚本然后修改警告/警告级别是合适的。似乎您希望编译器的某些执行发出尖叫声，但您希望继续执行其他操作。
So different compiler switches seems like a good way to go. You could do this with different targets - one labeled debug or release and the others labeled suitably about the warnings.
所以不同的编译器切换似乎是一个好方法。您可以使用不同的目标来执行此操作 - 一个标记为 debug 或 release，其他标记为有关警告的适当标记。
回答by jalf
It seems to me the root problem is really a combination of your treating warnings as errors, when they are clearly not, and your apparent policy of permitting check-ins which violate this. As you say, you want to be able to continue working despite a warning. You've only mentioned a few warnings you want to be able to ignore, but what if someone else on the team caused any other type of warning, which would take you equally long to fix? Wouldn't you want to be able to ignore that as well?
在我看来，根本问题实际上是您将警告视为错误（当它们显然不是错误时）以及您允许违反此规定的签入的明显政策的组合。正如您所说，尽管有警告，您仍希望能够继续工作。您只提到了一些您希望能够忽略的警告，但是如果团队中的其他人引起了任何其他类型的警告，这将花费您同样长的时间来修复怎么办？难道您不想也可以忽略它吗？
The logical solution would be to either 1) Disallow checkins if the code doesn't compile (which means those who created the warnings will have to fix them, since in effect, they broke the build), or 2) treat warnings as warnings. Create two build configurations, one which treats warnings as errors, which can be run regularly to ensure that the code is warning-free, and another, which only treats them as warnings, and allows you to work even if someone else introduced a warning.
合乎逻辑的解决方案是 1) 如果代码无法编译，则禁止签入（这意味着创建警告的人必须修复它们，因为实际上他们破坏了构建），或者 2) 将警告视为警告。创建两个构建配置，一个将警告视为错误，可以定期运行以确保代码无警告，另一个仅将它们视为警告，即使其他人引入警告也允许您工作。
回答by jalf
pragma warning (C# Reference)
pragma 警告（C# 参考）
pragma warning may be used to enable or disable certain warnings.
pragma warning 可用于启用或禁用某些警告。
http://msdn.microsoft.com/en-us/library/441722ys(VS.80).aspx
http://msdn.microsoft.com/en-us/library/441722ys(VS.80).aspx
回答by jalf
/warnaserror /warnaserror-:618
/warnaserror /warnaserror-:618
回答by jalf
or more specifically, in your case:
或更具体地说，就您而言：
/warnaserror /warnaserror-:612,1030,1701,1702
/warnaserror /warnaserror-:612,1030,1701,1702
this should treat all warnings as errors except for the ones in your comma separated list
这应该将所有警告视为错误，但逗号分隔列表中的警告除外
回答by Rinat Abdullin
I'm using treat warnings as errors.
我正在使用将警告视为错误。
In a rare cases, when some acceptable warning shows up (i.e. referencing obsolete member, or missing documentation on XML serialization classes), then it has to be explicitly suppressed with #pragma disable(and optionally reason for not having a clean code could be provided as a comment along).
在极少数情况下，当出现一些可接受的警告时（即引用过时的成员，或缺少有关 XML 序列化类的文档），则必须使用 #pragma disable显式抑制它（并且可以选择提供没有干净代码的原因）作为评论）。
Presence of this directive also allows to find out, who accepted this warning violation(by "blame" action of version control) in case there are some questions.
该指令的存在还允许找出谁接受了这个警告违规（通过版本控制的“责备”行动），以防万一有一些问题。
回答by erikkallen
Why not simply have a rule saying "Whoever checks in code with any warning inside it other than 612, 1030, 1701 or 1702 in it must go to the whiteboard and write a hundred times 'I will not check in code with disallowed warnings again.'"
为什么不简单地制定一条规则，说“签入代码中除了 612、1030、1701 或 1702 之外的任何警告的代码都必须到白板上写一百次‘我不会再次签入带有不允许警告的代码。 '"
