Tengo un marco basado en .NET 3.5 existente que se extiende mediante complementos personalizados. En resumen, los complementos implementan una interfaz común y el marco central los invoca a través de la reflexión. El marco funciona perfectamente y todo está bien, sin embargo ...Pregunta de diseño - Manejo de la configuración de la aplicación .NET en un nivel de DLL
Ahora tengo un requisito que requiere un complemento que se comunique con el servicio WCF. A simple vista, esto es simple, agregue una referencia de servicio al complemento, llame al código proxy del cliente y listo. Sin embargo ...
Debido a la forma en que funciona la configuración de .NET, la configuración del cliente del servicio WCF debe residir dentro del app.config de la aplicación en ejecución. En este caso, esta es mi aplicación de invocación de complemento. El problema con esto es que rompe el "modelo" de complemento ya que la aplicación de invocador genérica ahora debe tener una configuración específica de complemento dentro de ella.
Entonces, la pregunta es, ¿alguien sabe de un mecanismo alternativo para manejar la configuración del cliente del servicio WCF sin ponerlo en la configuración de la aplicación invocador central?
Después de un poco de búsqueda existen mecanismos para permitir una DLL to use its own config file. El problema aquí es que no tengo acceso al código subrayado de la creación del proxy de servicio y, por lo tanto, aparentemente no puedo redirigir las lecturas de configuración.
probablemente estoy totalmente fuera en la comprensión del tema, pero ¿es posible extender el contrato del complemento para incluir un método de inicialización del servicio? Luego, sus complementos basados en servicios implementan ese contrato como opuesto al general. Esto le permitiría descargar material de inicialización del servicio al desarrollador del complemento sin preocuparse por detalles de la inicialización. –