Provides a mechanism for releasing unmanaged resources.
To browse the .NET Framework source code for this type, see the Reference Source.
Assemblies: System.Runtime (in System.Runtime.dll)
mscorlib (in mscorlib.dll)
Thetype exposes the following members.
To view the .NET Framework source code for this type, see the Reference Source. You can browse through the source code online, download the reference for offline viewing, and step through the sources (including patches and updates) during debugging; see instructions.
The primary use of this interface is to release unmanaged resources. The garbage collector automatically releases the memory allocated to a managed object when that object is no longer used. However, it is not possible to predict when garbage collection will occur. Furthermore, the garbage collector has no knowledge of unmanaged resources such as window handles, or open files and streams.
Use the Dispose method of this interface to explicitly release unmanaged resources in conjunction with the garbage collector. The consumer of an object can call this method when the object is no longer needed.
It is a breaking change to add the interface to an existing class. Because pre-existing consumers of your type cannot call Dispose, you cannot be certain that unmanaged resources held by your type will be released.
Because the IDisposable.Dispose implementation is called by the consumer of a type when the resources owned by an instance are no longer needed, you should either wrap the managed object in a SafeHandle (the recommended alternative), or you should override Object.Finalize to free unmanaged resources in the event that the consumer forgets to call Dispose.
In the .NET Framework, the C++ compiler supports deterministic disposal of resources and does not allow direct implementation of the Dispose method.
Using an object that implements IDisposable
Implement only if you are using unmanaged resources directly. If your app simply uses an object that implements , don't provide an implementation. Instead, you should call the object's IDisposable.Dispose implementation when you are finished using it. Depending on your programming language, you can do this in one of two ways:
By using a language construct such as the using statement in C# and Visual Basic.
By wrapping the call to the IDisposable.Dispose implementation in a try/catch block.
Documentation for types that implement note that fact and include a reminder to call its Dispose implementation.
If your language supports a construct such as the using statement in C# and the Using statement in Visual Basic, you can use it instead of explicitly calling IDisposable.Dispose yourself. The following example uses this approach in defining a WordCount class that preserves information about a file and the number of words in it.
The using statement is actually a syntactic convenience. At compile time, the language compiler implements the intermediate language (IL) for a try/catch block.
If your programming language does not support a construct like the using statement in C# or Visual Basic, or if you prefer not to use it, you can call the IDisposable.Dispose implementation from the finally block of a try/catch statement. The following example replaces the using block in the previous example with a try/catch/finally block.
You should implement only if your type uses unmanaged resources directly. The consumers of your type can call your IDisposable.Dispose implementation to free resources when the instance is no longer needed. To handle cases in which they fail to call Dispose, you should either use a class derived from SafeHandle to wrap the unmanaged resources, or you should override the Object.Finalize method for a reference type. In either case, you use the Dispose method to perform whatever cleanup is necessary after using the unmanaged resources, such as freeing, releasing, or resetting the unmanaged resources.
If you are defining a base class that uses unmanaged resources and that either has, or is likely to have, subclasses that should be disposed, you should implement the IDisposable.Dispose method and provide a second overload of Dispose, as discussed in the next section.
IDisposable and the inheritance hierarchy
A base class with subclasses that should be disposable must implement as follows. You should use this pattern whenever you implement on any type that isn't sealed (NotInheritable in Visual Basic).
It should provide one public, non-virtual Dispose() method and a protected virtual Dispose(Boolean disposing) method.
The Dispose() method must call Dispose(true) and should suppress finalization for performance.
The base type should not include any finalizers.
The following code fragment reflects the dispose pattern for base classes. It assumes that your type does not override the Object.Finalize method.
If you do override the Object.Finalize method, your class should implement the following pattern.
Subclasses should implement the disposable pattern as follows:
They must override Dispose(Boolean) and call the base class Dispose(Boolean) implementation.
They can provide a finalizer if needed. The finalizer must call Dispose(false).
Note that derived classes do not themselves implement the interface and do not include a parameterless Dispose method. They only override the base class Dispose(Boolean) method.
The following code fragment reflects the dispose pattern for derived classes. It assumes that your type does not override the Object.Finalize method.
.NET FrameworkSupported in: 4.5.3, 4, 3.5, 3.0, 2.0, 1.1, 1.0
.NET Framework Client ProfileSupported in: 4, 3.5 SP1
Portable Class LibrarySupported in: Portable Class Library
.NET for Windows Store appsSupported in: Windows 8
Supported in: Windows Phone 8.1
Supported in: Windows Phone Silverlight 8.1
Supported in: Windows Phone Silverlight 8
Windows Phone 8.1, Windows Phone 8, Windows 8.1, Windows Server 2012 R2, Windows 8, Windows Server 2012, Windows 7, Windows Vista SP2, Windows Server 2008 (Server Core Role not supported), Windows Server 2008 R2 (Server Core Role supported with SP1 or later; Itanium not supported)
The .NET Framework does not support all versions of every platform. For a list of the supported versions, see .NET Framework System Requirements.