Cómo configurar WCF en un proyecto dll diferente

Question

Estoy desarrollando una aplicación web (ASP.NET 3.5) que consumirá una serie de servicios web. Creé un proyecto dll independiente para cada servicio web: estos proyectos contienen la referencia del servicio y el código del cliente.

Sin embargo, el sitio web de la llamada deberá tener la información <system.serviceModel> (los <bindings> y <client> nodos) en ella de web.config, a pesar de que esta información también se encuentra en el archivo app.config de la DLL! Intenté copiar el archivo serviceclass.dll.config en el directorio bin del sitio web, pero esto no me ayudó.

¿Hay alguna forma de centralizar la configuración de un cliente WCF?

Answer 1

Solo tengo experiencia WCF limitada, todas con enlaces BasicHTTP. Pero soy alérgico a los archivos xml de WCF y he logrado evitarlos hasta ahora. No lo recomiendo en general, pero pongo los detalles de configuración en el almacén de configuración existente de mi aplicación y luego los aplico programáticamente. P.ej. Con un proxy de servicio web utilizo el constructor para el Cliente que toma 'bindings' y 'endpoint' y aplica programáticamente la configuración al enlace & endpoint.

Parece que se describe una solución más elegente aquí: Reading WCF Configuration from a Custom Location, pero aún no lo he probado.

Answer 2

Es posible renunciar a las configuraciones xml y crear las clases de enlace y punto final asociadas con el servicio en el constructor o una "Fábrica de servicio" personalizada. iDesign tiene una buena información sobre esto: http://www.idesign.net/idesign/DesktopDefault.aspx?tabindex=5&tabid=11 (Ver En Proc fábrica)

En su enfoque, se establece atributos en sus servicios para especificar en un nivel alto de cómo deben trabajar (es decir, [Internet], [Intranet] , [BusinessToBusiness]), y la fábrica de servicios configura el servicio de acuerdo con las mejores prácticas para cada escenario. Su libro describe la construcción de este tipo de servicio: http://www.amazon.com/Programming-WCF-Services-Juval-Lowy/dp/0596526997

Si lo que desea es compartir de configuración XML de configuración, tal vez utilizar el configSource atributo para especificar una ruta para la configuración: http://weblogs.asp.net/cibrax/archive/2007/07/24/configsource-attribute-on-system-servicemodel-section.aspx

Answer 3

Desde mi experiencia, los proyectos de bibliotecas nunca leyeron app.config.

Así que realmente puede eliminar el archivo porque no se utiliza. En su lugar, se lee la configuración de host de la biblioteca, por lo que ese es el único lugar donde debe estar la configuración de enlace y punto final.

Answer 4

Recuerde que un archivo de configuración es leído por un ejecutable que tiene un punto de entrada. Un dll de biblioteca no tiene un punto de entrada, por lo que no será el ensamblado el que lo leerá. El ensamblaje de ejecución debe tener un archivo de configuración para leer.

Si desea centralizar sus configuraciones web, le sugiero que busque anidarlas en IIS con directorios virtuales. Esto le permitirá usar la herencia de configuración para centralizar lo que necesite.

Answer 5

En primer lugar, las bibliotecas de clases (DLL) no tienen su propia configuración, sin embargo, pueden leer la configuración de su host (Web/Executable, etc.). Dicho esto, todavía mantengo un archivo app.config en los proyectos de la biblioteca como una plantilla y referencia fácil.

En cuanto a la configuración del servicio en sí, la configuración de WCF puede hacer que alguien se quite fácilmente el pelo. Es una pieza demasiado complicada y sobrediseñada.El objetivo de sus aplicaciones debe depender menos de la configuración, manteniendo al mismo tiempo la flexibilidad de los escenarios de implementación que su producto va a encontrar.

Answer 6

Hay 2 opciones.

Opción 1. Trabajar con canales.

Si está trabajando con canales directamente, .NET 4.0 y .NET 4.5 tienen el ConfigurationChannelFactory. El ejemplo de MSDN se ve así:

ExeConfigurationFileMap fileMap = new ExeConfigurationFileMap(); 
fileMap.ExeConfigFilename = "Test.config"; 
Configuration newConfiguration = ConfigurationManager.OpenMappedExeConfiguration(
    fileMap, 
    ConfigurationUserLevel.None); 

ConfigurationChannelFactory<ICalculatorChannel> factory1 = 
    new ConfigurationChannelFactory<ICalculatorChannel>(
     "endpoint1", 
     newConfiguration, 
     new EndpointAddress("http://localhost:8000/servicemodelsamples/service")); 
ICalculatorChannel client1 = factory1.CreateChannel(); 

como ha señalado Langdon, puede utilizar la dirección de punto final del archivo de configuración simplemente pasando en nulo, como esto:

var factory1 = new ConfigurationChannelFactory<ICalculatorChannel>(
     "endpoint1", 
     newConfiguration, 
     null); 
ICalculatorChannel client1 = factory1.CreateChannel(); 

Esto se discute en el MSDN documentation.

Opción 2. Trabajar con proxies.

Si está trabajando con proxies generados por código, puede leer el archivo de configuración y cargar un archivo ServiceModelSectionGroup. Hay un poco más de trabajo que implica que el simple uso de la ConfigurationChannelFactory pero al menos se puede continuar utilizando el proxy generado (que bajo el capó utiliza un ChannelFactory y gestiona el IChannelFactory para usted.

Pablo Cibraro muestra un buen ejemplo de esto aquí : Getting WCF Bindings and Behaviors from any config source