CF 1.0 is a bit different. I don't know of any way to actually view the object graphs or find out if the finalizer mechanism is the same as the desktop framework and CF 2.0. However, this blog post[^] suggests that, as elsewhere, the objects requiring finalization are placed on a separate queue processed by a background thread. System.ComponentModel.Component does not have a finalizer, so classes deriving from it do not automatically get a cleanup penalty as happens in CF 2.0. It does not implement the IDisposable interface, though, nor a Dispose method, although it does have a protected virtual Dispose(bool) method. All this does is to fire the Disposed event. In addition, System.ComponentModel.Component does not implement the IComponent interface! That means you can't add them to System.ComponentModel.Container, so you can't take advantage of the container's support for disposing all of its contained components when it is disposed. This makes Container completely useless so they should have omitted it. However, many of the components that derive from Component have their own finalizer. MainMenu falls into this category. However, it does not provide a Dispose method and doesn't implement IDisposable. The best you can hope for is to disconnect it from the form, by setting the form's Menu property to null, then you can manually suppress finalization with GC.SuppressFinalize(). You really have to inspect the implementation (using Reflector[^], for example) to see how to clean up one of these classes appropriately. Using Reflector just on the assemblies that ship with .NET Compact Framework 1.0 SP3, I see that the following classes derive from Component and have finalizers: Microsoft.WindowsCE.Forms.InputPanel System.Windows.Forms.ImageList System.Windows.Forms.ContextMenu System.Windows.Forms.MainMenu System.Windows.Forms.Timer so these are all classes to watch out for. The SqlConnection, SqlCeConnection etc. classes also derive from Component but they do implement IDisposable, and it's a lot less common to drop them on forms. Of these, ImageList is little bother because it doesn't have any events or references to anything else, so it can't hold anything else in memory. It's d
