wsdl.exe/svcutil.exe: esiste un modo per non generare le classi per i tipi xsds durante un servizio Web o generazione di client

Question

Abbiamo un modello a oggetti gestito centralmente per i tipi nello schema in C#. Vogliamo che tutti all'interno dell'azienda utilizzino tale modello di oggetto invece di utilizzare quello generato ogni volta da wsdl/svcutil durante l'implementazione di un client o di un servizio webservice.

c'è un parametro (in qualsiasi altro modo) per wsdl/svcutil non generare classi per i tipi di schema durante l'esecuzione?

Answer 1

Se si rimuove l'endpoint mex dal file di configurazione del servizio, l'app client non sarà in grado di rilevare e generare gli oggetti proxy.

Un modo per gestire questa situazione, se ho capito la tua domanda correttamente è quello di effettuare le seguenti operazioni:

1. Creare un insieme comune di DLL che ha il servizio, e datacontracts/modello di oggetto condiviso.
2. Creare un servizio utilizzando i contratti nella dll comune anziché i contratti creati dallo studio di visualizzazione quando si crea un nuovo servizio.
3. Rimuovere l'endpoint MEX dal file di configurazione del server (questo interromperà sostanzialmente la generazione del proxy).
4. Chiedi al tuo cliente di utilizzare la dll comune e creare manualmente i canali sul lato client (tramite factory di canale ecc.).

In questo approccio non si utilizza wsdl.exe/svcutil.exe poiché si sta essenzialmente bypassando il wsdl. Non si aggiungono riferimenti al servizio poiché si gestiscono manualmente le connessioni.

EDIT: Seguendo questo approccio, il client può ancora provare a generare oggetti proxy tramite wsdl.exe/svcutil.exe, ma non otterranno le informazioni corrette da wsdl. Genereranno essenzialmente un proxy non funzionante/incompleto.

Answer 2

Non conosco alcuna impostazione specifica o interruttore della riga di comando per far rispettare questo - cosa si può fare, ma si tratta principalmente di addestramento e applicazione controllando, è di condividere la libreria di classi (l'assembly, in un DLL) con gli sviluppatori, e fare in modo che tutti fa riferimento a tale libreria di classi comuni e lascia le impostazioni predefinite nella finestra di dialogo "Add Service Reference" (nella pagina "Avanzate") da solo:

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

Qui, si definisce che WCF riutilizzerà tutti i tipi che può trovare in uno qualsiasi degli assembly referenziati, quindi se gli sviluppatori aggiungono un riferimento regolare alla libreria di contratti di dati comuni, WCF utilizzerà quelli t invece di ricrearli più e più volte.

Ma ancora una volta - questo è solo un tipo di approccio "gestione con esempi e controllo" - non conosco alcun modo tecnico per far rispettare questo.

Answer 3

Credo che quello che stai cercando è: svcutil.exe /r your-dtos.dll

/di riferimento: - tipi riferimento nel assembly specificato. Quando si generano client, utilizzare questa opzione per specificare gli assembly che potrebbero contenere tipi che rappresentano i metadati importati.(Short: /r)

A mio parere il forte accoppiamento del proxy WCF, canale di endpoint, le operazioni di servizio e carichi utili DTO nello stesso proxy client generato è un importante difetto di progettazione.

Questo è ciò che mi ha spronato a risolvere nel mio open web services framework dove ho disaccoppiare il punto finale e del carico utile che permette di:

• Il cliente stesso servizio web (es Soap11, Soap12, XML, JSON) per essere in grado di chiama qualsiasi servizio web.
• Mi consente inoltre di utilizzare la stessa istanza dto DataContract in qualsiasi client del servizio Web
• Questo ha molti vantaggi, tra cui la possibilità di esporre lo stesso servizio Web su un numero di endpoint diversi senza alcuna configurazione aggiuntiva. Fornendo così endpoint di servizi Web ottimizzati per ciascun utente del mio servizio. Per esempio.
  • XML per i clienti di interoperabilità e fortemente tipo,
  • JSON per i clienti Ajax,
  • WSDL di per ambienti che preferiscono generato il codice (ad esempio Flex Builder, VS.NET 'Aggiungi riferimento al servizio' ecc)

Nella mia azienda abbiamo sviluppato centinaia di servizi web chiamati da un certo numero di clienti diversi, vale a dire l'Ajax, Flash/ActionScript, C++, Silverlight, ASP.NET e di essere in grado di chiamare lo stesso servizio web attraverso diversi punti finali ha ti ho salvato s innumerevoli ore.