Llamar a un servicio WCF sin generar un ensamblaje

Question

Estoy intentando escribir algún código en C# que llame a un servicio WCF sobre la marcha importando el WSDL, examinándolo y luego haciendo llamadas a él dinámicamente.

El servicio al que estoy llamando puede cambiar de vez en cuando, por lo que quiero que mi cliente conozca nuevos métodos y nuevos parámetros de entrada y salida para las llamadas, sin reconstruir mi cliente.

Una posible solución a esto es importar y compilar una referencia de servicio sobre la marcha.

esbozado aquí: Creating an assembly on the fly from a WSDL

me gustaría evitar la generación de un ensamblaje y luego reflexionar sobre ella, si es posible.

Miré en el código del proxy dinámico en el enlace y usan una clase de marco para hacer la importación. Esta clase es WsdlImporter. Así que lo pensé muy bien: puedo usar eso y examinar el esquema WSDL y determinar qué llamadas están presentes y qué entradas y salidas están disponibles.

El problema es que la información de tipo falta en los objetos MessagePartDescription que crea el WsdlImporter. Aparentemente esto falta because it cannot find the types yet - see the response to the question from Brian.

¿Algún consejo sobre cómo debo proceder? ¿Estoy completamente en el camino equivocado aquí?

Answer 1

Probablemente esta no sea una respuesta, pero la publicaré como una para describir completamente mi opinión.

Proxy dinámico:
IMO esto es un ejemplo de uso incorrecto de la tecnología. Es un comportamiento elemental de WSDL: si cambia debe cambiar de cliente o debe realizar un buen versionado de WSDL y crear un nuevo cliente.

Todavía tiene que decir de alguna manera que su cliente obtenga WSDL, ¿significa que analizará WSDL antes de cada llamada? No parece una buena idea

La información sobre los tipos realmente no forma parte de WSDL porque, de forma predeterminada, WSDL se genera como interoperable. Los tipos de CLR no son operaciones necesarias para la interoperabilidad. Cuando crea un proxy de servicio mediante Agregar referencia de servicio o Svcutil, generará código para los tipos definidos en WSDL. Ese código luego necesita ser compilado.

Puede intentar utilizar NetDataContractSerializer en lugar de DataContractSerializer predeterminado. NetDataContractSerializer agrega información de tipo CLR a WSDL, pero aún espero que los nuevos tipos sean conocidos por sus clientes, es decir, implementar nuevos ensamblajes con tipos y usarlos por los clientes. Esto casi suena como el mismo enfoque cuando simplemente se implementa el ensamblado con un nuevo proxy de cliente estático.

dinámico WF cliente
Asimismo, no veo mucho uso de esta arquitectura - que todavía tienen que cambiar cliente para reflejar las nuevas medidas de WF, ¿verdad?

Cambiando la WF
¿Estamos hablando de la fundación Windows Workflow? Apenas puedo imaginar el escenario donde se crea WF, se lo expone como un servicio y luego se lo cambia. Cuando expone WF como servicio, probablemente esté definiendo WF de larga ejecución. Las WF de larga ejecución usan persistencia basada en la serialización (al menos en WF 3.5 pero creo que es lo mismo en WF 4).Cuando cambias la definición de WF, todos los WF persistentes probablemente están condenados porque nunca se deserializarán. Esta situación generalmente se resuelve mediante el despliegue paralelo de la versión nueva y antigua, donde la versión anterior solo se utiliza para finalizar archivos WF incompletos. Nuevamente significa nuevos clientes.

Answer 2

Si observa el problema desde un ángulo diferente. ¿Necesita volver a generar el proxy cada vez o necesita un contrato que continúe funcionando cuando cambien las cosas?

WCF tiene un mecanismo para esta IExtensibleDataContracts ver: http://msdn.microsoft.com/en-us/library/ms731083%28v=VS.100%29.aspx

Las mejores prácticas para el control de versiones de los contratos se pueden encontrar here