wsdl.exe/svcutil.exe - hay una manera de no generar las clases para los tipos en los xsds durante un servicio web o generación de clientes

Question

Tenemos un modelo de objetos administrado centralmente para los tipos en el esquema en C#. Queremos que todos los empleados de la empresa usen ese modelo de objetos en lugar de usar el que se genera cada vez desde wsdl/svcutil durante la implementación de un servicio web o cliente.

¿hay algún parámetro (de cualquier otra forma) que wsdl/svcutil no genere clases para los tipos de esquema durante su ejecución?

Answer 1

Si elimina el punto final mex del archivo de configuración del servicio, la aplicación cliente no podrá descubrir y generar los objetos proxy.

Una manera de manejar esta situación si entiendo bien su pregunta es hacer lo siguiente:

1. crear un conjunto común de DLL que tiene el servicio, y DataContracts/modelo de objeto compartido.
2. Cree un servicio utilizando los contratos en el dll común en lugar de los contratos que visual studio crea cuando crea un nuevo servicio.
3. Elimina el punto final MEX del archivo de configuración del servidor (esto esencialmente interrumpirá la generación del proxy).
4. Haga que su cliente use el dll común y cree manualmente los canales en el lado del cliente (a través de la fábrica de canales, etc ...).

En este enfoque, no use wsdl.exe/svcutil.exe en absoluto, ya que esencialmente está pasando por alto el wsdl. No agrega referencias de servicio ya que está administrando manualmente las conexiones.

EDITAR: Siguiendo este enfoque, el cliente aún puede intentar generar objetos proxy a través de wsdl.exe/svcutil.exe, pero no obtendrán la información correcta del wsdl. En esencia, generarán un proxy incompleto/que no funcione.

Answer 2

No conozco ningún ajuste específico o cambio de línea de comando para hacer cumplir esto - lo que puede hacer, pero eso es principalmente una cuestión de capacitación y ejecución mediante verificación, es compartir la biblioteca de clase (el ensamblado, en DLL) con los desarrolladores, y asegurarse de que todo el mundo hace referencia a que la biblioteca de clases común y deja la configuración predeterminada en el cuadro de diálogo "Agregar referencia de servicio" (en la página "avanzada") por sí sola:

alt text http://i45.tinypic.com/11b68sh.png

Aquí, usted define que WCF reutilizará cualquier tipo que pueda encontrar en cualquiera de los ensamblados a los que se hace referencia, de modo que si sus desarrolladores agregan una referencia regular a la biblioteca de contratos de datos comunes, WCF usará esos t ypes en lugar de volver a crearlos una y otra vez.

Pero, nuevamente, eso es solo un enfoque de "gestión mediante el ejemplo y el control": no conozco ninguna forma técnica de hacer cumplir esto.

Answer 3

Creo que lo que busca es: svcutil.exe /r your-dtos.dll

/referencia: - tipos referencia en el ensamblado especificado. Al generar clientes, use esta opción para especificar conjuntos que pueden contener tipos que representan los metadatos que se importan.(Corta: /r)

En mi opinión, el acoplamiento ajustado del proxy de WCF, punto final del canal, las operaciones de servicio y cargas útiles dto en el mismo proxy cliente generado es un importante fallo de diseño.

Esto es lo que me impulsó a resolver en mi open web services framework donde desacoplar el punto final y la carga útil que permite:

• El cliente mismo servicio web (es decir Soap11, soap12, XML, JSON) para poder llamar a cualquier servicio web.
• También me permite usar la misma instancia de DataContract dto en cualquiera de los clientes del servicio web
• Esto tiene muchos beneficios, incluyendo la posibilidad de exponer el mismo servicio web en una serie de puntos finales diferentes sin ninguna configuración adicional. De este modo, proporcionar puntos finales de servicio web optimizados para cada consumidor de mi servicio. P.ej.
  • XML para los clientes de interoperabilidad y fuertemente del tipo,
  • JSON para clientes Ajax,
  • WSDL para entornos que prefieren generan código (es decir, Flex Builder, VS.NET 'Agregar referencia de servicio', etc)

en mi empresa hemos desarrollado cientos de servicios web denominados por un número de clientes distintos, es decir, Ajax, flash/ActionScript, C++, Silverlight, ASP.NET y ser capaz de llamar a la misma a través del servicio web tiene diferentes criterios de valoración te salvó s innumerables horas.