Al crear un componente .NET designable, debe proporcionar un constructor predeterminado. Desde elComponente documentación:

Para ser un componente, una clase debe implementar la interfaz IComponent y proporcionar un constructor básico que no requiera parámetros o un solo parámetro de tipo IContainer.

Esto hace que sea imposible hacer una inyección de dependencia a través de argumentos del constructor. (Se podrían proporcionar constructores adicionales, pero el diseñador los ignoraría). Algunas alternativas que estamos considerando:

Localizador de servicios

No use la inyección de dependencias, en su lugar use el patrón de localización de servicios para adquirir dependencias. Esto parece ser lo que IComponent.Site.GetService es para. Supongo que podríamos crear una implementación ISite reutilizable (¿ConfigurableServiceLocator?) Que se puede configurar con las dependencias necesarias. Pero, ¿cómo funciona esto en un contexto de diseñador?

Inyección de dependencias vía propiedades

Inyectar dependencias a través de propiedades. Proporcione instancias predeterminadas si son necesarias para mostrar el componente en un diseñador. Documente qué propiedades necesitan ser inyectadas.

Inyectar dependencias con un método de inicialización.

Esto es muy parecido a la inyección a través de propiedades, pero mantiene la lista de dependencias que se deben inyectar en un solo lugar. De esta manera, la lista de dependencias requeridas se documenta implícitamente, y el compilador lo asistirá con los errores cuando la lista cambie.

¿Alguna idea de cuál es la mejor práctica aquí? ¿Cómo lo haces?

editar: He eliminado "(por ejemplo, un WinForms UserControl)" ya que pretendía que la pregunta fuera sobre los componentes en general. Los componentes son todos acerca de la inversión de control (ver sección 8.3.1 de laEspecificación UMLv2) así que no creo que "no deberías inyectar ningún servicio" es una buena respuesta.

editar 2: Tomó un poco de juego con WPF y el patrón MVVM para finalmente "obtener" la respuesta de Mark. Ahora veo que los controles visuales son de hecho un caso especial. En cuanto al uso de componentes no visuales en superficies de diseñador, creo que el modelo de componentes .NET es fundamentalmente incompatible con la inyección de dependencia. Parece estar diseñado alrededor del patrón del localizador de servicios. Tal vez esto comience a cambiar con la infraestructura que se agregó en .NET 4.0 en elSystem.ComponentModel.Composition espacio de nombres.