Consumare webservice da una DLL NET - problema app.config

Question

Sto costruendo una DLL, chiamiamola mydll.dll, e in essa io a volte hanno bisogno di chiamare i metodi da webservice, myservice. mydll.dll viene creato utilizzando C# e .NET 3.5.

di consumare myservice da mydll ho aggiunto un servizio in Visual Studio 2008, che è più o meno lo stesso che utilizzare svcutil.exe. In questo modo si crea una classe che posso creare e si aggiungono configurazioni di endpoint e binding a mydll app.config.

Il problema qui è che mydll app.config non viene mai caricato. Invece, ciò che è caricata è l'app.config o web.config del programma che uso mydll in.

mi aspetto mydll ad evolversi, ed è per questo che ho disaccoppiato è funcionality dal resto del mio sistema iniziare con. Durante questa evoluzione probabilmente aggiungerà più servizi web a cui chiamerà, escludendo i modi manuali copia-incolla per superare questo problema.

Ho guardato diversi approcci possibili per attaccare questo problema:

1. Copiare manualmente gli endpoint e attacchi da mydell app.config per indirizzare EXE o web file .config.
   Coppie i moduli, non flessibili
2. includono endpoint e attacchi da mydll app.config in .config bersaglio, utilizzando configSource (vedi here). aggiungere anche accoppiamento tra moduli
3. carico di programmazione mydll app.config, leggere endpoint e attacchi ed istanziare rilegatura e EndpointAddress.
4. utilizzare uno strumento diverso per creare frontend locale myservice

Non sono sicuro di quale strada da percorrere. L'opzione 3 sembra promettente, ma a quanto pare è un sacco di lavoro e probabilmente introdurrà diversi bug, quindi si ripaga senza dubbio. Inoltre non ho familiarità con nessun altro strumento oltre al canonico svcutil.exe.

Si prega di dare pro e contro per l'alternativa di cui sopra, fornire suggerimenti per l'attuazione di uno di essi o suggerire altri approcci.

Grazie,
Asaf

Answer 1

Preferisco opzione 5 - "Nella configurazione del codice", sì sì sì, si perde il beneficio di modifica, senza ricompilare, ma dipende da ciò che è necessario. Se sai che non cambierai mai i tuoi endpoint o cambierai raramente - basta fare la tua configurazione in codice, riceverai il tempo di compilazione come bonus =) This e this possono aiutarti.

E btw, configurazione nel file di configurazione del client è un caso comune, se avete un sacco di questi clienti questo può essere il dolore e si dovrebbe pensare a 3 o 5 =)

Answer 2

dovrei andare da l'opzione 1 o 2 (per me questo è meglio). I moduli sono accoppiati nella DLL, quindi sono già accoppiati. Cambiare una configurazione è banale, ma fare un'infrastruttura per leggere ti accorgerà di più.

Le opzioni 3 e 4 richiedono molto più lavoro.

Answer 3

Ho compilato la mia open source web services framework fino a anche una singola dll. Sebbene abbia adottato un approccio completamente diverso, ho creato IH HTTPHandler generico per gli endpoint JSON e XML (e la configurazione WCF generica per gli endpoint SOAP) in grado di gestire la richiesta ogni. Quindi la mia configurazione è una semplice linea singola per tutti i dei miei servizi Web che associano l'endpoint al gestore che risiede con il file .config dell'host dell'applicazione (ad esempio ASP.NET Web.config o Console App.config) dove è destinato a essere.

Answer 4

È possibile utilizzare svcutil come evento post-build nell'applicazione che sta utilizzando la DLL. Come questo:

svcutil.exe <service_address> /config:$(TargetPath).config /mergeConfig 

Ciò si fonderà la configurazione necessaria in yourapp.exe.config. Se aggiungi un nuovo riferimento al servizio nella DLL, dovresti aggiungere un'altra linea qui, quindi non è completamente automatico, ma è ancora più semplice della copia manuale della configurazione.