当 .NET初创的时候，关于IDisposable该如何使用存在一定的不确定性。结果，IDisposable的应用方式过于激进，许多种类的类都需要空的Dispose方法。这给静态分析工具带来了一些问题，它们无法将实际缺少Dispose调用与误报区分开来。

为了理解始末缘由，我们需要回过头看一下CLR早期的历史以及垃圾收集是如何运行的。最初，CLR的目的在于是作为Visual Basic的新运行时，在20世纪90年代末Visual Basic是基于COM的。在COM模型下，对象会有一个引用计数。在引用创建和销毁的时候，引用计数会随之进行更新，如果计数变成零，对象就会被释放。这样的话，就形成了一个具有确定性的垃圾收集模型，在这种模型中，我们可以确切地知道该在什么时候清理资源。

引用方式的垃圾收集模型的最明显缺点就在于它很容易出现内存泄露。如果我们创建了一系列的对象，它们之间互相循环引用的话，每个对象都会让其他对象的引用计数无法降低到零，从而会出现内存泄露。在多线程环境中，它还会产生性能问题，因为在调整引用计数的时候，需要用到锁。

在开发的早期，微软决定采用标记-清理（mark-and-sweep）垃圾收集器来让CLR避免这些问题。随着Java的流行，这种方式在社区中得到了普遍的认可。但是，这种方式的GC并不能确定地释放资源，这使得它不适合用于数据库连接、文件处理和其他高度受限的资源。因此，IDisposable应运而生。

与此同时，微软正在试验“组件”的理念。组件的概念从来没有被很好地定义。在这方面，有Component类，以及像IComponent、IContainer和ISite这样的接口。在将近20年之后，文档中也只有一个很模糊的注释：“应用程序之间的对象共享”。其想法大概和COM类似，也就是某个应用可以直接与其他程序进行交互。但是，这并没有达到目的，所以被埋没在历史的故纸堆中了。

而在Windows Forms中，有一个不同的“组件”概念，它真正的意思是“可以放到表单/窗口（form/window）中的内容”。除了像文本框这样的实际UI元素之外，还包括添加了特定功能的对象，如计时器。这来自VB 6编程时代，当时几乎所有想使用的内容都必须要放到表单中。甚至数据库连接和命令也可以直接放到表单中。

这也就是为什么我们看到很多毫不相关的对象也标记成了IDisposable。像DataTable和SqlCommand并没有要处理的非托管资源，但是在过去我们错误地认为最好将它们放到表单中，所以它们继承了Component类。而Component是disposable的，所以我们可以选择何时关闭代理对象。

静态分析

随着静态分析逐渐从高级工具变成了每个开发人员都该使用的工具，关于disposable对象不断增长的告警越来越成为一个问题。对于像SqlCommand这样短期存活的对象来说，这还不算太糟糕，因为可以很容易地使用using语句对其进行包装，而不需要考虑该语句实际上并没有执行任何操作。

像DataTable这样的类就比较困难了。这是一个长期存活的对象，它所使用的地方可能距离创建它的地方非常远。除非设置为suppressed或禁用，否则静态分析工具将会报告DataTable和类似对象有未处理处理的告警和错误。

DisposeUnusedAttribute提议

“最佳”方案是彻底移除所有无用的Dispose方法。但是，这并不是可行方案，因为这样会破坏向后的兼容性。

Edward Brey提出了一个相当简单而优雅的解决方案。他建议创建一个DisposeUnused属性来屏蔽静态分析工具。子类不会继承此属性。

但是，这个设计也并非尽善尽美。一旦DisposeUnused用到了某个类上，移除它将会是破坏性的变更。对于DataTable来说，这并不是什么问题，不过，Stephen A. Imhoff提供一个这样的样例。

这实际上会更糟糕，因为现在你可能会说“好的，忽略该契约，我就是这样声明的”，如果某个类型突然需要dispose某个资源的话（比如说，MemoryStream要为大型数组或其他内容分配一个原生数组），那么你的消费者需要执行dispose操作，但是你之前却告诉人家不需要这样做……

另一个问题是你并不是总能知道变量里有什么。假设有一个类型为Component的变量。在编译时，我们无法判断放入变量的内容是否需要dispose处理。因此，更有意义的做法是只将DisposeUnused用到密闭类（sealed classed）中，这些类是无法子类化的。

原文链接：
A Proposal for IDisposable and Static Analysis: DisposeUnused Attribute

创作场景

对 IDisposable 和静态分析的提议：DisposeUnused 属性