Comment configurer la WCF dans une dll projet

Je suis de développement d'une application web (ASP.NET 3.5) qui va consommer un certain nombre de services web. J'ai créé une dll-projet pour chaque service web: ces projets contient la référence de service et code client.

Toutefois, le site web DOIT avoir la <system.serviceModel> de l'information (la <bindings> et <client> nœuds) du web.config, même si cette information est également dans la dll de l'application.fichier de config! J'ai essayé de copier le serviceclass.dll.config sur le répertoire bin du site, mais cela n'a pas aide.

Est-il un moyen de centraliser la configuration d'un WCF client?

Pour quiconque recherche cela, jetez un oeil à cette réponse: stackoverflow.com/a/839941/592732

OriginalL'auteur edosoft | 2009-02-02

4

J'ai seulement limitée WCF de l'expérience, tous avec BasicHTTP liaisons. Mais je suis allergique à la WCF fichiers xml et ont réussi à éviter jusqu'à présent. Je ne recommandons pas cela en général, mais j'ai mis les détails de la configuration dans mes applications existantes magasin de configuration puis de les appliquer par programmation. E. g. Avec un proxy de service Web je utiliser le constructeur pour le Client qui prend un 'liaisons et de" point de terminaison " et par programmation d'appliquer les paramètres pour les liaisons & point de terminaison.

Plus elegent solution semble être décrite ici: La lecture de Configuration WCF à partir d'un Emplacement Personnalisé, mais je n'ai pas encore essayé.

Je vous remercie. J'ai essayé de code dans le lien que vous avez fourni et c'est exactement ce que je veux.

OriginalL'auteur codybartfast
4

De mon expérience, de projets de bibliothèque n'a jamais lu app.config.

De sorte que vous pouvez vraiment supprimer le fichier car il n'est pas utilisé. La bibliothèque de la configuration de l'hôte est de lire au lieu de cela, de sorte que c'est le seul endroit où le terminal et la configuration de liaison devrait être.

exactement - si vous avez une DLL qui est hébergé ou utilisé par une application, seulement l'application de la configuration de la matière. C'est un .NET conception de base de décision. C'est pourquoi les paramètres dans le projet DLL de l'application.config ne sera pas utilisé À TOUS.... 🙁

OriginalL'auteur AlexDrenea
3

Il est possible de renoncer à xml de config et de construire la Liaison et le point de Terminaison de classes associées avec le service dans le constructeur ou une coutume "Service de l'Usine". iDesign a quelques bonnes informations sur ce:
http://www.idesign.net/idesign/DesktopDefault.aspx?tabindex=5&tabid=11
(Voir Dans La Proc Usine)

Dans leur approche, vous définissez des attributs sur vos services pour spécifier à un niveau élevé, comment ils doivent travailler (c'est à dire [Internet], [Intranet], [BusinessToBusiness]), et le service de l'usine permet de configurer le service selon les meilleures pratiques pour chaque scénario. Leur livre décrit la construction de ce type de service:
http://www.amazon.com/Programming-WCF-Services-Juval-Lowy/dp/0596526997

Si vous souhaitez partager de configuration XML de config, peut-être utiliser la configSource attribut pour spécifier un chemin d'accès pour la configuration: http://weblogs.asp.net/cibrax/archive/2007/07/24/configsource-attribute-on-system-servicemodel-section.aspx

OriginalL'auteur Daniel
3

Rappelez-vous qu'un fichier de configuration est lu par un fichier exécutable qui est un point d'entrée. Une bibliothèque dll n'a pas de point d'entrée de sorte qu'il n'est pas l'assemblée qui va le lire. L'exécution de l'assemblage doit avoir un fichier de configuration à lire.

Si vous souhaitez centraliser vos web configs alors je vous suggère de regarder dans imbriquant dans IIS avec des répertoires virtuels. Cela vous permettra d'utiliser la configuration de l'héritage de centraliser tout ce dont vous avez besoin.

OriginalL'auteur Andrew Hare
1

Il y a 2 options.

L'Option 1. Travailler avec des chaînes.

Si vous travaillez avec des chaînes directement .NET 4.0 et .NET 4.5 a la ConfigurationChannelFactory. L'exemple sur MSDN ressemble à ceci:
```
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();
```
Comme l'a souligné Langdon, vous pouvez utiliser l'adresse de point de terminaison du fichier de configuration par simple passage de la valeur null, comme ceci:
```
var factory1 = new ConfigurationChannelFactory<ICalculatorChannel>(
        "endpoint1", 
        newConfiguration, 
        null);
ICalculatorChannel client1 = factory1.CreateChannel();
```
Cela est décrit dans la MSDN la documentation.

L'Option 2. L'utilisation de serveurs proxy.

Si vous travaillez avec le code généré par proxy, vous pouvez lire le fichier de configuration et de charger un ServiceModelSectionGroup. Il y a un peu plus de travail que d'utiliser simplement le ConfigurationChannelFactory mais au moins, vous pouvez continuer à utiliser le proxy généré (que sous le capot utilise un ChannelFactory et gère le IChannelFactory pour vous.

Pablo pablo cibraro montre un bel exemple de cela ici: L'obtention de la WCF les Liaisons et les Comportements à partir de toute source de config

OriginalL'auteur Philippe
0

Tout d'abord la classe des bibliothèques (Dll) n'ont pas leur propre configuration, cependant, on peut lire la configuration de leur hôte (Web/Exécutables, etc.). Cela étant dit, je maintiens toujours un app.fichier de configuration sur les projets de la bibliothèque en tant que modèle et de référence.

Autant que la configuration du service lui-même est concerné, configuration WCF peut faire à quelqu'facilement tirer les cheveux. Il est conçu sur-pièce compliquée. L'objectif de vos applications devraient être à dépendre moins de la configuration, tout en conservant la flexibilité des scénarios de déploiement de votre produit va venir à travers.

OriginalL'auteur Rajiv

Vous devez vous connecter pour publier un commentaire.