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

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

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

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

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

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

В их подходе вы устанавливаете атрибуты для своих сервисов, чтобы указать на высоком уровне, как они должны работать (например, [Интернет], [Интранет], [BusinessToBusiness]), а фабрика сервисов настраивает сервис в соответствии с передовыми практиками для каждого сценария. В их книге описывается создание такого рода сервиса: https://rads.stackoverflow.com/amzn/click/com/0596526997

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

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

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

Есть 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 из любого источника конфигурации

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

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