Decrements the reference count of the specified Runtime Callable Wrapper (RCW) associated with the specified COM object.
Assembly: mscorlib (in mscorlib.dll)
- Type: System.Object
The COM object to release.
Return ValueType: System.Int32
The new value of the reference count of the RCW associated with o. This value is typically zero since the RCW keeps just one reference to the wrapped COM object regardless of the number of managed clients calling it.
This method is used to explicitly control the lifetime of a COM object used from managed code. You should use this method to free the underlying COM object that holds references to resources in a timely manner or when objects must be freed in a specific order.
Every time a COM interface pointer enters the common language runtime (CLR), it is wrapped in an RCW.
The RCW has a reference count that is incremented every time a COM interface pointer is mapped to it. The method decrements the reference count of an RCW. When the reference count reaches zero, the runtime releases all its references on the unmanaged COM object, and throws a System.NullReferenceException if you attempt to use the object further. If the same COM interface is passed more than one time from unmanaged to managed code, the reference count on the wrapper is incremented every time, and calling returns the number of remaining references.
This method enables you to force an RCW reference count release so that it occurs precisely when you want it to. However, improper use of may cause your application to fail, or may cause an access violation.
Consider a scenario in which managed code in an application domain is holding onto an RCW that represents a COM component. If you call the method on the RCW, the managed code will be unable to access the RCW and will raise an InvalidComObjectException exception.
A more serious error may occur if a call to the RCW is executing when the RCW is released. In this case, there is a good chance that the thread making the call will cause an access violation. However, process memory may become corrupted, and the process may continue to run until it fails for reasons that are very difficult to debug.
This risk is compounded when the COM component that is being used is a singleton, for the following reason: The CLR activates COM components by calling the COM CoCreateInstance function, which returns the same interface pointer every time it is called for singleton COM components. Thus, separate and independent pieces of managed code in an application domain can be using the same RCW for a singleton COM component, and if either one calls the method on the COM component, the other will be broken.
Therefore, use the only if it is absolutely required. If you want to call this method to ensure that a COM component is released at a determined time, consider using the FinalReleaseComObject method instead. FinalReleaseComObject will release the underlying COM component regardless of how many times it has re-entered the CLR. The internal reference count of the RCW is incremented by one every time the COM component re-enters the CLR. Therefore, you could call the method in a loop until the value returned is zero. This achieves the same result as the FinalReleaseComObject method.
.NET FrameworkSupported in: 4.5.2, 4.5.1, 4.5, 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
.NET for Windows Phone appsSupported in: Windows Phone 8.1, Windows Phone 8, Silverlight 8.1
requires full trust for the immediate caller. This member cannot be used by partially trusted or transparent code.
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.