In this case, you should question the need for implementing this interface. Look at it: its members are only related to the disposing, and only for the purpose of using them in the designer:
http://msdn.microsoft.com/en-us/library/system.componentmodel.icomponent.aspx[
^].
You should understand that the platform is based on Garbage Collection, so finalization of most objects does not need to be addressed. The disposal mechanism is important for 1) hierarchical finalization typical for UI with its parent-child trees, hence in components, 2) for support of reclaiming of the unmanaged resource, 3) for support of the
using statement (
http://msdn.microsoft.com/en-us/library/yh598w02.aspx[
^]). Most types don't need any of these feature, absolute majority of them.
In your question, I see no indication of a need in any of the features typical for components. And, even if some of them require the use of the features 2-3, it is not related to
IComponent
interface. You should understand that having some types good for a universal type library does not mean making them components. Most of the library types should not be components.
And finally, (sigh…) I must say that I always criticized the idea of overusing the designer. Non-visual components available in component libraries should not really be components and used in the designer. I never add such things as timers in a designer. It's apparent that the designer is a slow and highly manual way of doing "programming". It is only good to define general layout. Putting many detail, especially repeated, only kills supportability of the project and delay development. Non-visual component only contaminate the designer's views. I think adding them is just the artificial marketing hype of Microsoft and some other companies. They demonstrate the product to non-programming representatives of other companies and try to create an illusion that it makes programming "easy", "visual" and "without coding". This is all not true. One problem (not very big though) of Microsoft is: they like to please the lamers. We need to learn how to avoid catching the bait. :-)
[EDIT #1]
Just for comparison, please see my past answer on the similar designer problem with XAML:
Event Occurring in the Form Life Cycle[
^].
[END EDIT #1]
[EDIT #2]
Please see my comment to the question below, in reply to your comment. Really, Visual Studio has some kind of design defect: if you create any file with the top-level class derived from the class
System.ComponentModel.Component
, directly or indirectly, Solution Explorer behaves in inadequate way: it shows some useless design window on double click (but correct code window on F7).
This is not just highly annoying; one can accidentally add components to this fake "design view" which just contaminate the project with fictitious artifacts.
You can use some artificial work-around to avoid it. First, you can declare these classes as nested classes of some other, say, static class serving just as the code scope. I don't like it, because the code is actually contaminated with something unnecessary; just wanted to mention it for understanding.
I prefer doing different thing, which is even more artificial and not obvious, but at least does not change anything essential. If you change the name of the file, this glitch will disappear. The file should be ended by ".designer.cs". (I use "designer", not "Designer", to create some difference with auto-generated files.)
Actually, I often use it for adding extra parts to
partial
form classes. If some form file is named, say, "MyForm", it creates the files "MyForm.cs" and "MyForm.Designer.cs". If I add some extra part for this class in a separate file, this file will show this redundant designer page, too. The problem disappears, as I names it, for example "MyForm.Setup.designer.cs", and so on.
I understand this work-around solution is a bit ugly, but what else could you suggest? Not changing Visual Studio or begging Microsoft to improve design, I hope… :-)
At least it works smoothly for me, so I can advise to for you, too.
[END EDIT #2]
—SA