在Visual Studio中“将所有警告视为错误除外…”
在Visual Studio中，如果存在任何警告，我可以select“将警告视为错误”选项以防止编译代码。 我们的团队使用这个选项，但有两个警告，我们希望保持警告。
有一个压制警告的选项，但我们希望它们显示为警告，所以这是行不通的。
看起来，获得我们想要的行为的唯一方法是在“特定警告”文本框中input每个C＃警告编号的列表，除了我们希望被视为警告的那两个。
我正在检查一个文件来源控制，以跟踪哪些我们被视为错误
C＃3.5警告号码视为错误：
183,184,197,420,465,602,626,657,658,672,684,688,809,824,1058,1060,1200, 1201,1202,1203,1522,1570,1574,1580,1581,1584,1589,1590,1592,1598,1607, 1616,1633,1634,1635,1645,1658,1682,1683,1684,1685,1687,1690,1691,1692, 1694,1695,1696,1697,1699,1707,1709,1720,1723,1911,1956,1957,2002,2014, 2023,2029,3000,3001,3002,3003,3004,3005,3006,3007,3008,3009,3010,3011, 3012,3013,3014,3015,3016,3017,3018,3022,3023,3026,3027,5000,108,114,162, 164,251,252,253,278,279,280,435,436,437,440,444,458,464,467,469,472,618, 652,728,1571,1572,1587,1668,1698,1710,1711,1927,3019,3021,67,105,168,169, 219,282,414,419,642,659,660,661,665,675,693,1700,1717,1718,28,78,109,402, 422,429,628,649,1573,1591,1610,1712,3024 警告编号保留为警告的C＃3.5：
612 - X is obsolete 1030 - #warning This is a warning 1701, 1702 - Warnings that are suppressed by the C# compiler by default and shouldn't show up at all.
这种方法最大的缺点是一些警告没有数字，所以不能被明确引用。 例如，“无法parsing此引用，无法find程序集”数据….“
有谁知道更好的方法来做到这一点？
澄清那些不立即看到为什么这是有用的人。 考虑大多数警告是如何工作的。 他们告诉你刚才写的代码里有一点点closures。 大约需要10秒来修复它们，并且保持代码基础更清洁。
“过时”的警告与此非常不同。 有时修复它意味着只是消耗一个新的方法签名。 但是，如果整个class级都过时了，而且你已经使用了数十万行代码，那么可能需要数周或更长的时间才能修复。 你不希望这个构build被破坏了很长时间，但是你一定想看到一个警告。 这不仅仅是一个假设的情况 – 这发生在我们身上。
文字“＃警告”警告也是独一无二的。 我经常想检查它，但我不想打破构build。
您可以在项目文件中添加一个WarningsNotAsErrors -tag。
<PropertyGroup> ... ... <WarningsNotAsErrors>618,1030,1701,1702</WarningsNotAsErrors> </PropertyGroup>
注意： 612和618都是关于Obsolete的警告，不知道有什么区别，但是我正在处理的项目是报告Obsolete with warning 618。
/ warnaserror / warnaserror-：618
或者更具体地说，在你的情况下：
/ warnaserror / warnaserror-：612,1030,1701,1702
这应该将所有警告视为错误，除了逗号分隔列表中的错误
为什么你要继续看到你不被视为错误的警告？ 我很困惑，为什么这是可取的 – 要么你修理它们，要么你不修理它们。
将两个不同的生成/解决scheme文件工作 – 或者一个脚本来复制一个，然后修改警告/警告级别适合。 看来也许你想要一些编译器的执行者发出警告，但是你想继续运行的其他人。
所以不同的编译器开关似乎是一个好方法。 你可以用不同的目标来做到这一点 – 一个标记为debugging或释放，另一个标记适当的警告。
我使用治疗警告作为错误。
在极less数情况下，当出现一些可接受的警告（即引用过时的成员，或者丢失XML序列化类的文档）时，必须使用#pragma disable明确禁止 （并且可能会提供没有干净代码的原因作为评论）。
这个指令的存在还允许找出谁接受了这个警告违规 （通过版本控制的“责备”动作），以防有一些问题。
为什么不简单地有一个规则：“除了612,1030,1701或1702以外的其他任何警告代码，必须进入白板书写一百次”我不会再次在禁止的代码中检查代码。 “”
在我看来，根本问题实际上是你的警告的组合，当它们显然不是这样的错误时，以及你明显的允许违反这个规定的检查的政策。 正如你所说，你希望能够继续工作，尽pipe警告。 你只提到了一些你希望能够忽略的警告，但是如果团队中的其他人引起了其他types的警告，那么你会等待很长时间才能解决？ 你不希望能够忽略这一点吗？
合乎逻辑的解决scheme是1）不允许检查代码是否不编译（这意味着那些创build警告的人将不得不修复它们，因为它们实际上打破了构build），或者2）将警告视为警告。 创build两个构buildconfiguration，一个将警告视为错误，可以定期运行以确保代码无警告，另一个只将其视为警告，即使其他人引入了警告，也允许您运行。
