Come configurare WCF in un progetto di DLL separato

Question

Sto sviluppando un'applicazione Web (ASP.NET 3.5) che consumerà un numero di servizi Web. Ho creato un progetto dll separato per ogni servizio Web: questi progetti contengono il riferimento del servizio e il codice client.

Tuttavia, il sito chiamante deve avere la <system.serviceModel> informazioni (i <bindings> e <client> nodi) in esso di web.config, anche se questa informazione è anche nel file app.config del dll! Ho provato a copiare serviceclass.dll.config nella directory bin del sito Web, ma questo non ha aiutato.

C'è un modo per centralizzare la configurazione di un client WCF?

Answer 1

Ho solo limitato l'esperienza WCF, tutte con associazioni BasicHTTP. Ma sono allergico ai file xml di WCF e sono riuscito a evitarli fino ad ora. Non lo raccomando generalmente, ma inserisco i dettagli di configurazione nel mio negozio di configurazione esistente e li applico in modo programmatico. Per esempio. Con un proxy del servizio Web, utilizzo il costruttore per il client che accetta "binding" e "endpoint" e applica le impostazioni in modo programmabile all'endpoint & dei binding.

Una soluzione più elegante sembra essere descritta qui: Reading WCF Configuration from a Custom Location, ma non l'ho ancora provato.

Answer 2

È possibile rinunciare alla configurazione xml e creare le classi Binding ed Endpoint associate al servizio nel costruttore o una "Fabbrica servizi" personalizzata. iDesign ha alcune buone informazioni su questo: http://www.idesign.net/idesign/DesktopDefault.aspx?tabindex=5&tabid=11 (Vedi in Proc fabbrica)

Nel loro approccio, è possibile impostare gli attributi per i propri servizi per specificare ad alto livello come dovrebbe funzionare (cioè [Internet], [Intranet] , [BusinessToBusiness]) e la fabbrica di servizi configura il servizio in base alle migliori pratiche per ogni scenario. Il loro libro descrive la costruzione di questo tipo di servizio: http://www.amazon.com/Programming-WCF-Services-Juval-Lowy/dp/0596526997

Se si desidera condividere configurazione XML di configurazione, magari utilizzare il configSource attributo per specificare un percorso per la configurazione: http://weblogs.asp.net/cibrax/archive/2007/07/24/configsource-attribute-on-system-servicemodel-section.aspx

Answer 3

Dalla mia esperienza, progetti di libreria mai letto app.config.

Quindi è possibile davvero eliminare il file perché non viene utilizzato. La configurazione host della libreria viene invece letta, quindi questo è l'unico posto in cui dovrebbero trovarsi l'endpoint e la configurazione di binding.

Answer 4

Ricordare che un file di configurazione viene letto da un eseguibile che ha un punto di ingresso. Una DLL di libreria non ha un punto di ingresso, quindi non è l'assembly a leggerlo. L'assembly in esecuzione deve avere un file di configurazione da leggere.

Se si desidera centralizzare le proprie configurazioni Web, suggerirei di cercare di annidarle in IIS con le directory virtuali. Ciò ti consentirà di utilizzare l'ereditarietà della configurazione per centralizzare tutto ciò che ti serve.

Answer 5

Prima di tutto le librerie di classi (DLL) non dispongono di una propria configurazione, tuttavia possono leggere la configurazione del loro host (Web/eseguibile ecc.). Detto questo, mantengo ancora un file app.config sui progetti della libreria come modello e facile riferimento.

Per quanto riguarda la configurazione del servizio, la configurazione di WCF può far sì che qualcuno si tiri fuori facilmente i capelli. È un pezzo troppo complicato e troppo ingegnerizzato.L'obiettivo delle tue applicazioni dovrebbe dipendere meno dalla configurazione, mantenendo al contempo la flessibilità degli scenari di distribuzione che il tuo prodotto sta per incontrare.

Answer 6

Ci sono 2 opzioni.

Opzione 1. Utilizzo dei canali.

Se si sta lavorando direttamente con i canali, .NET 4.0 e .NET 4.5 ha il ConfigurationChannelFactory. L'esempio a MSDN si presenta così:

ExeConfigurationFileMap fileMap = new ExeConfigurationFileMap(); 
fileMap.ExeConfigFilename = "Test.config"; 
Configuration newConfiguration = ConfigurationManager.OpenMappedExeConfiguration(
    fileMap, 
    ConfigurationUserLevel.None); 

ConfigurationChannelFactory<ICalculatorChannel> factory1 = 
    new ConfigurationChannelFactory<ICalculatorChannel>(
     "endpoint1", 
     newConfiguration, 
     new EndpointAddress("http://localhost:8000/servicemodelsamples/service")); 
ICalculatorChannel client1 = factory1.CreateChannel(); 

Come sottolineato da Langdon, è possibile utilizzare l'indirizzo dell'endpoint dal file di configurazione semplicemente passando in nulla, in questo modo:

var factory1 = new ConfigurationChannelFactory<ICalculatorChannel>(
     "endpoint1", 
     newConfiguration, 
     null); 
ICalculatorChannel client1 = factory1.CreateChannel(); 

Questo è discusso nel MSDN documentation.

Opzione 2. Utilizzo di proxy.

Se si sta lavorando con i proxy generati dal codice, è possibile leggere il file di configurazione e caricare uno ServiceModelSectionGroup. C'è un po 'più di lavoro coinvolti che semplicemente utilizzando il ConfigurationChannelFactory, ma almeno si può continuare a utilizzare il proxy generato (che sotto il cofano utilizza un ChannelFactory e gestisce il IChannelFactory per voi.

Pablo Cibraro mostra un bel esempio di questo qui : Getting WCF Bindings and Behaviors from any config source