If you looked at the documentation, you'd see that a Component (or other IComponent implementation) is anything that can be contained with in a container, or more specifically IContainer. The biggest difference? A Control is graphical and has concepts such as location and size, where a Component isn't necessarily graphical. Take the FileSystemWatcher for example. It obviously has no UI associated with it since it just watches files and uses Win32/NT-based APIs. It does, however, have an icon associated with it in design-time. This is because it's a component and can be dragged and dropped onto the design surface. This allows code monkeys to click on it and set properties and event handlers using VS.NET (or any other emerging designer these days). You can, of course, forget about the whole component architecture and type it manually, but this allows the component to be "designed". So, when should you use a control and when should you use a component? If you plan on displaying any UI, you must inherit from control since only controls in the parent's Controls collection are displayed - and it only takes a Control or a child class of it. If you want your "object" to be tied to a designer (even extending the designer with your own ComponentDesigner), you can make it derive from Component. .NET has several examples, such as the FileSystemWatcher, the EventLog, and many, many more. Just go to the overview documentation for the Component class and click on "Derived Classes" toward the top of the page.
-----BEGIN GEEK CODE BLOCK----- Version: 3.21 GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++ -----END GEEK CODE BLOCK-----