Как настроить WCF в отдельном проекте DLL - PullRequest
Новая
       10

Как настроить WCF в отдельном проекте DLL

7 голосов
/ 02 февраля 2009

Я занимаюсь разработкой веб-приложения (ASP.NET 3.5), которое будет использовать несколько веб-сервисов. Я создал отдельный dll-проект для каждого веб-сервиса: эти проекты содержат ссылку на сервис и код клиента.

Однако вызывающий веб-сайт ДОЛЖЕН иметь информацию <system.serviceModel> (узлы <bindings> и <client>) в своем файле web.config, хотя эта информация также находится в файле app.config библиотеки dll! Я попытался скопировать serviceclass.dll.config в каталог bin сайта, но это не помогло.

Есть ли способ централизовать настройку клиента WCF?

Ответы [ 6 ]

4 голосов
/ 02 февраля 2009

По моему опыту, библиотечные проекты никогда не читают app.config.

Таким образом, вы действительно можете удалить файл, потому что он не используется. Вместо этого читается конфигурация хоста библиотеки, поэтому это единственное место, где должна быть конфигурация конечной точки и привязки.

4 голосов
/ 02 февраля 2009

У меня только ограниченный опыт WCF, все с привязками BasicHTTP. Но у меня аллергия на XML-файлы WCF, и до сих пор мне удалось их избежать. Я не рекомендую это вообще, но я помещаю детали конфигурации в существующее хранилище конфигурации моих приложений и затем применяю их программно. Например. С прокси-сервером веб-службы я использую конструктор для клиента, который принимает «привязки» и «конечную точку» и программно применяет настройки к привязкам и конечной точке.

Здесь описывается более простое решение: Чтение конфигурации WCF из пользовательского местоположения , но я еще не пробовал.

3 голосов
/ 02 февраля 2009

Помните, что файл конфигурации читается исполняемым файлом, имеющим точку входа. Библиотека DLL не имеет точки входа, поэтому сборка не будет читать ее. У исполняющей сборки должен быть файл конфигурации для чтения.

Если вы хотите централизовать свои веб-конфигурации, я бы посоветовал вам вложить их в IIS с виртуальными каталогами. Это позволит вам использовать наследование конфигурации для централизации всего, что вам нужно.

3 голосов
/ 02 февраля 2009

Можно отказаться от конфигурации xml и создать классы Binding и Endpoint, связанные со службой, в конструкторе или в пользовательской «фабрике служб». У iDesign есть хорошая информация по этому вопросу: http://www.idesign.net/idesign/DesktopDefault.aspx?tabindex=5&tabid=11 (См. В Proc Factory)

В их подходе вы устанавливаете атрибуты в своих сервисах, чтобы на высоком уровне указывать, как они должны работать (т. Е. [Интернет], [Интранет], [BusinessToBusiness]), а фабрика сервисов настраивает сервис в соответствии с рекомендациями каждый сценарий. Их книга описывает создание такого рода услуг: http://www.amazon.com/Programming-WCF-Services-Juval-Lowy/dp/0596526997

Если вы просто хотите поделиться конфигурацией XML config, возможно, используйте атрибут configSource, чтобы указать путь для конфигурации: http://weblogs.asp.net/cibrax/archive/2007/07/24/configsource-attribute-on-system-servicemodel-section.aspx

1 голос
/ 16 апреля 2013

Есть 2 варианта.

Вариант 1. Работа с каналами.

Если вы работаете с каналами напрямую, в .NET 4.0 и .NET 4.5 имеется ConfigurationChannelFactory . Пример на MSDN выглядит следующим образом: 

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();

Как указал Лэнгдон, вы можете использовать адрес конечной точки из файла конфигурации, просто передав NULL, например: 

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

Это обсуждается в документации MSDN .

Вариант 2. Работа с прокси.

Если вы работаете с сгенерированными кодом прокси, вы можете прочитать файл конфигурации и загрузить ServiceModelSectionGroup . Требуется немного больше работы, чем просто использование ConfigurationChannelFactory, но по крайней мере вы можете продолжать использовать сгенерированный прокси (который под капотом использует ChannelFactory и управляет IChannelFactory для вас.

Пабло Сибраро показывает хороший пример этого здесь: Получение привязок и поведения WCF из любого источника конфигурации

0 голосов
/ 11 января 2013

Прежде всего библиотеки классов (DLL) не имеют своей собственной конфигурации, однако они могут читать конфигурацию своего хоста (Web / Executable и т. Д.). При этом я все еще сохраняю файл app.config в проектах библиотеки как шаблон и легкий справочник.

Что касается самой конфигурации сервиса, конфигурация WCF может заставить кого-то легко выдернуть свои волосы. Это чрезмерно сложный и сложный предмет. Цель ваших приложений должна состоять в том, чтобы как можно меньше зависеть от конфигурации, при этом сохраняя гибкость сценариев развертывания, с которыми столкнется ваш продукт.

...