Domanda

Sto sviluppando un'applicazione Web (ASP.NET 3.5) che utilizzerà numerosi servizi Web. Ho creato un progetto dll separato per ciascun servizio Web: questi progetti contengono il riferimento al servizio e il codice client.

Tuttavia, il sito Web chiamante DEVE avere le informazioni <system.serviceModel> (i nodi <bindings> e <client>) nel suo web.config, anche se queste informazioni sono anche nel file app.config della dll! Ho provato a copiare serviceclass.dll.config nella directory bin del sito Web, ma questo non ha aiutato.

Esiste un modo per centralizzare la configurazione di un client WCF?

È stato utile?

Soluzione

Ho solo un'esperienza WCF limitata, il tutto con i collegamenti BasicHTTP. Ma sono allergico ai file xml di WCF e finora sono riuscito a evitarli. Non lo consiglio in generale, ma inserisco i dettagli di configurazione nell'archivio di configurazione esistente delle mie app e quindi li applico in modo programmatico. Per esempio. Con un proxy del servizio Web utilizzo il costruttore per il client che accetta "bind" e "endpoint" e applica programmaticamente le impostazioni all'amplificatore &; endpoint.

Una soluzione più elegante sembra essere descritta qui: Lettura della configurazione WCF da una posizione personalizzata , ma non l'ho ancora provato.

Altri suggerimenti

Dalla mia esperienza, i progetti di biblioteca non leggono mai app.config.

Quindi puoi davvero cancellare il file perché non è usato. Viene invece letta la configurazione host della libreria, quindi è l'unica posizione in cui dovrebbero trovarsi l'endpoint e la configurazione di binding.

È possibile rinunciare alla configurazione xml e creare le classi Binding ed Endpoint associate al servizio nel costruttore o un " personalizzato; Service Factory " ;. iDesign ha alcune buone informazioni al riguardo: http://www.idesign.net/idesign/ ? & DesktopDefault.aspx tabindex = 5 amp; tabid = 11 (Vedi In Proc Factory)

Nel loro approccio, imposti attributi sui tuoi servizi per specificare ad alto livello come dovrebbero funzionare (es. [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 solo condividere la configurazione XML config, utilizzare l'attributo configSource per specificare un percorso per la configurazione: http://weblogs.asp.net/cibrax/archive/2007/07/24/configsource-attribute-on-system-servicemodel -section.aspx

Ricorda che un file di configurazione viene letto da un eseguibile che ha un punto di ingresso. Una libreria DLL non ha un punto di ingresso quindi non è l'assembly che lo leggerà. L'assembly in esecuzione deve avere un file di configurazione da leggere.

Se desideri centralizzare le tue configurazioni web, ti suggerirei di cercare di annidarle in IIS con directory virtuali. Ciò ti consentirà di utilizzare l'eredità della configurazione per centralizzare tutto ciò di cui hai bisogno.

Ci sono 2 opzioni.

Opzione 1. Lavorare con i canali.

Se si lavora direttamente con i canali, .NET 4.0 e .NET 4.5 hanno ConfigurationChannelFactory . L'esempio su MSDN è simile al seguente :

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 null, in questo modo:

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

Questo è discusso nella MSDN documentazione .

Opzione 2. Lavorare con i proxy.

Se si lavora con proxy generati dal codice, è possibile leggere il file di configurazione e caricare un ServiceModelSectionGroup . È necessario un po 'più di lavoro rispetto al semplice utilizzo di ConfigurationChannelFactory ma almeno puoi continuare a utilizzare il proxy generato (che sotto il cofano utilizza un ChannelFactory e gestisce il IChannelFactory per te.

Pablo Cibraro mostra un bell'esempio di questo qui: Ottenere collegamenti e comportamenti WCF da qualsiasi fonte di configurazione

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

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

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top