Initialization and Termination of Components
Your component is initialized by its constructor (Sub New in Visual Basic) and destroyed by its destructor (Sub Finalize in Visual Basic). Your component's constructor is called when an instance of your component is created; the constructor cannot be called thereafter. The destructor is called just before your component is destroyed by garbage collection and its memory is reclaimed.
.gif) Visual Basic Note |
|---|
In previous versions of Visual Basic, the Initialize and Terminate events served the same purpose as the constructor and destructor. |
Waiting for Garbage Collection
The common language runtime calls your component's destructor after the garbage collection determines that the component can no longer be reached by any executing code. This happens if all references to the component have been released, or if the only references to your component are held by objects that are similarly isolated from all executing code — for example, in the case of circular references.
Because there can be a delay between the moment when a user is finished with your component and the moment when its destructor is called, an additional step is introduced into the lifetime of .NET Framework components: If your component acquires system resources, such as database connections or handles to Windows system objects, you should implement the IDisposable interface, and provide a Dispose method so that users of your component can choose when to release those resources.
Life Cycle of a Component
Type initialization: When the first instance of your component is created, the first code that executes is any shared initialization code. A reference to any shared member will also cause the shared constructor to execute. This includes any shared fields (member variables) that are initialized, and the shared constructor (Shared Sub New) if it exists. In the following code, a reference font is created for the entire class.
| Note |
|---|
The C# keyword that corresponds to Shared is static, which is not to be confused with the Static keyword in Visual Basic. |
When Should You Implement a Dispose Method?
If your component inherits from Component, a default implementation of Dispose is provided. This implementation can be overridden to provide custom cleanup code. If you are building your component by creating a custom implementation of IComponent, you should implement IDisposable to provide a Dispose method for your component.
Your component needs a Dispose method if it allocates system objects, database connections, or other scarce resources that should be released as soon as a user is finished with the component.
You should also implement a Dispose method if your component holds references to other objects that have Dispose methods.
Why Implement Dispose?
Depending on system activity, an unpredictable interval could elapse between the time a user finishes using your component and the time garbage collection detects that the component's code is unreachable. If you do not provide a Dispose method, your component will continue to hold its resources during this interval.
A Worst-Case Scenario
Imagine a server component that uses a database connection and does not have a Dispose method. On a server with a large amount of memory, you might create and release many instances of the component without having much impact on free memory. In this case, garbage collection might not destroy the components for some time after the references to them are released.
Eventually, all of the available database connections could be tied up by components that had been released but not destroyed. Even though the server had no shortage of memory, it might be unable to respond to user requests.
See Also
Tasks
How to: Create and Configure Components in Design Mode
Reference
Concepts
Component Class Characteristics
Component Instancing Changes in Visual Basic