在 C # 中禁止“ is never used”和“ is never sent to”警告

我在 C # 项目中有一个 httpsystemdefinitions.cs 文件，它基本上描述了旧的 windows ISAPI，可以通过托管代码使用。

这包括与 ISAPI 相关的结构的完整集合，而不是全部或由代码使用。在编译时，这些结构的所有字段成员都会发出如下警告:-

警告字段‘ UnionSquare.ISAPI.HTTP _ FILTER _ PREPROC _ HEADERS. SetHeader’永远不会被分配，并且它的默认值始终为 null

或者

警告字段“ UnionSquare.ISAPI.HTTP _ FILTER _ PREPROC _ HEADERS. HttpStatus”从不使用

Can these be disabled with #pragma warning disable? If so what would the corresponding error numbers be? If not is there anything else I can do? Bear in mind that I only what to do this for this file, its important that I get see warnings like these coming from other files.

剪辑

示例结构:-

struct HTTP_FILTER_PREPROC_HEADERS
{
//
//  For SF_NOTIFY_PREPROC_HEADERS, retrieves the specified header value.
//  Header names should include the trailing ':'.  The special values
//  'method', 'url' and 'version' can be used to retrieve the individual
//  portions of the request line
//


internal GetHeaderDelegate GetHeader;
internal SetHeaderDelegate SetHeader;
internal AddHeaderDelegate AddHeader;


UInt32  HttpStatus;               // New in 4.0, status for SEND_RESPONSE
UInt32  dwReserved;               // New in 4.0
}
71736 次浏览
小开
最佳答案

Yes, these can be suppressed.

Normally, I'm opposed to suppressing warnings, but in this case, structs used for interop absolutely requires some fields to be present, even though you never intend to (or can) use them, so in this case I think it should be justified.

通常，要禁止显示这两个警告，您需要修复违规代码。第一个(“ ... 从不使用”)通常是代码的味道，来自早期版本的代码。也许代码被删除了，但字段留下了。

第二种通常是用于错误使用字段的代码嗅觉。例如，您可能错误地将属性的新值写回属性本身，而不是写回备份字段。

要禁止显示“ 字段 XYZ 从不使用”警告，请执行以下操作:

#pragma warning disable 0169
... field declaration
#pragma warning restore 0169

要禁止显示“ Field XYZ is never assigned to, and will always have its default value XX”警告，请执行以下操作:

#pragma warning disable 0649
... field declaration
#pragma warning restore 0649

为了自己找到这些警告号码(比如，我怎么知道要用0169和0649) ，你可以这样做:

  • Compile the code as normal, this will add some warnings to your error list in Visual Studio
  • 切换到 Output 窗口和 Build 输出，并寻找相同的警告

  • Copy the 4-digit warning code from the relevant message, which should look like this:

    C: Dev VS.NET Console Application19 Console Application19 Program.cs (10,28) : 警告 CS0649: 字段“ Console Application19.Program.dwReserve”永远不是 分配给，并且始终具有其默认值0

警告 : 根据 @ Jon Hanna的评论，对于这个问题和答案的未来发现者，可能需要一些警告。

  • 首先，也是最重要的一点，抑制警告的行为类似于吞下治疗头痛的药丸。当然，有时这可能是正确的做法，但这不是一个万能的解决方案。有时候，头痛是一个真正的症状，你不应该掩饰，同样的警告。最好尝试通过修复警告的原因来处理它们，而不是仅仅盲目地从构建输出中删除它们。
  • 话虽如此，如果您需要隐藏警告，请遵循我上面列出的模式。第一行代码 #pragma warning disable XYZK禁用警告 for the rest of that file，或者至少禁用到找到相应的 #pragma warning restore XYZK为止。尽量减少禁用这些警告的行数。上面的模式只禁用一行的警告。
  • 还有，就像 Jon 提到的，一个关于你为什么这么做的评论是个好主意。禁用警告无疑是一种无缘无故的代码嗅觉，注释将防止未来的维护人员花费时间思考您为什么这样做，或者甚至删除它并尝试修复警告。
小开

I got VS to generate the implementation skeleton for System.ComponentModel.INotifyPropertyChanged and the events were implemented as fields which triggered the CS0067 warnings.

作为公认答案 我将字段转换为属性，警告消失了中给出的解决方案的替代方案。

这是有意义的，因为属性声明语法 Sugar 被编译成一个字段，加上引用该字段的 getter 和/或 setter 方法(在我的例子中是 add/delete)。这满足编译器的要求，并且不会引发警告:

struct HTTP_FILTER_PREPROC_HEADERS
{
//
//  For SF_NOTIFY_PREPROC_HEADERS, retrieves the specified header value.
//  Header names should include the trailing ':'.  The special values
//  'method', 'url' and 'version' can be used to retrieve the individual
//  portions of the request line
//


internal GetHeaderDelegate GetHeader {get;set;}
internal SetHeaderDelegate SetHeader { get; set; }
internal AddHeaderDelegate AddHeader { get; set; }


UInt32 HttpStatus { get; set; }               // New in 4.0, status for SEND_RESPONSE
UInt32 dwReserved { get; set; }               // New in 4.0
}
小开

修复这些警告的另一个“解决方案”是使用结构 public。然后不发出警告，因为编译器不知道是否在程序集外使用(分配)字段。

也就是说，“互操作”组件通常不应该是公共的，而应该是 internal或 private。

小开

C/C + + 用户使用 (void)var;来禁止显示未使用的变量警告。 @ Peng 在评论中指出，可变丢弃可用于抑制警告:

_ = variable;

这可能是自 C # 7.0以来就有的，C # 7.0在语言语法中引入了下划线的使用。在该语言的早期版本中，对于定义了位运算符的类型，曾经可以使用位运算符在 C # 中禁止显示未使用的变量警告:

uint test1 = 12345;
test1 |= 0; // test1 is still 12345


bool test2 = true;
test2 &= false; // test2 is now false

使用这种策略当然是可疑的，而且是作为最后的手段。最好升级语言支持并使用变量丢弃语法。


提交答案