Chiamare un servizio WCF senza generare un assembly

Question

Sto provando a scrivere del codice in C# che richiamerà immediatamente un servizio WCF importando il WSDL, esaminandolo e quindi effettuando le chiamate dinamicamente.

Il servizio che sto chiamando può cambiare di volta in volta, quindi se lo desidera voglio che il mio cliente sappia nuovi metodi e nuovi parametri di input e parametri di output per le chiamate, senza ricostruire il mio client.

Una possibile soluzione a questo è di importare e compilare un servizio di riferimento al volo.

qui descritte: Creating an assembly on the fly from a WSDL

desidero evitare la generazione di un assieme e poi riflettendo su di esso, se possibile.

Ho esaminato il codice del proxy dinamico nel collegamento e utilizzano una classe framework per eseguire l'importazione. Questa classe è WsdlImporter. Così ho pensato benissimo - posso usarlo ed esaminare lo schema WSDL e determinare quali chiamate sono presenti e quali input e output sono disponibili.

Il problema è che le informazioni sul tipo sono mancanti negli oggetti MessagePartDescription creati da WsdlImporter. Apparentemente questo è mancante because it cannot find the types yet - see the response to the question from Brian.

Quindi qualche consiglio su come dovrei procedere? Sono completamente sulla strada sbagliata qui?

Answer 1

Questa probabilmente non è una risposta, ma la posterò per descrivere pienamente la mia opinione.

Proxy dinamico:
IMO questo è un esempio di utilizzo errato della tecnologia. È un comportamento elementare di WSDL - se cambia si deve cambiare client o si deve fare un buon versionamento WSDL e creare un nuovo client.

Devi ancora dire in qualche modo al tuo cliente di ottenere WSDL - vuol dire che analizzerai WSDL prima di ogni chiamata? Non sembra una buona idea.

Le informazioni sui tipi non fanno realmente parte di WSDL perché per impostazione predefinita WSDL viene generato come interoperabile. I tipi CLR non sono operazioni necessarie per l'interoperabilità. Quando crei il proxy del servizio tramite Aggiungi riferimento al servizio o Svcutil, genererà il codice per i tipi definiti in WSDL. Quindi quel codice deve essere compilato.

È possibile provare a utilizzare NetDataContractSerializer anziché il valore predefinito DataContractSerializer. NetDataContractSerializer aggiunge le informazioni sul tipo CLR in WSDL, ma mi aspetto ancora che i nuovi tipi debbano essere conosciuti dai client: significa distribuire nuovo assembly con tipi e usarlo dai client. Sembra quasi lo stesso approccio quando si distribuisce semplicemente l'assembly con un nuovo proxy client statico.

dinamica WF cliente
anche io non vedo troppo uso di questa architettura - è comunque necessario cambiare client per riflettere nuovi passi WF, non è vero?

Modifica della WF
Stiamo parlando di Windows Workflow Foundation? Riesco a malapena a immaginare uno scenario in cui si crea WF, esporlo come servizio e quindi modificarlo. Quando esponi WF come servizio, probabilmente stai definendo WF a lungo termine. I file WF a lunga esecuzione usano la persistenza basata sulla serializzazione (almeno in WF 3.5, ma credo che sia la stessa in WF 4).Quando modifichi la definizione WF, tutti i file WF persistenti sono probabilmente condannati perché non verranno mai deserializzati. Questa situazione viene in genere risolta mediante l'implementazione parallela di versioni nuove e vecchie in cui la vecchia versione viene utilizzata solo per completare WF incomplete. Di nuovo significa nuovi clienti.

Answer 2

Se si osserva il problema da un'angolazione diversa. Hai bisogno di rigenerare il proxy ogni volta o hai bisogno di un contratto che continua a funzionare quando le cose cambiano?

WCF ha un meccanismo per questo IExtensibleDataContracts vedere: http://msdn.microsoft.com/en-us/library/ms731083%28v=VS.100%29.aspx

Le migliori pratiche per il controllo delle versioni dei contratti si possono trovare here