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

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

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

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

источник

2009-02-02 edosoft

Для тех, кто ищет это, взгляните на этот ответ: http://stackoverflow.com/a/839941/592732 – MarioVW

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

Более элегантное решение похоже на descib здесь: Reading WCF Configuration from a Custom Location, но я еще не пробовал.

источник

2009-02-02 12:47:39 codybartfast

Спасибо. Я попытался закодировать ссылку, которую вы предоставили, и это делает именно то, что я хочу. – edosoft

Возможно изменить конфигурацию xml и создать классы привязки и конечной точки, связанные с сервисом в конструкторе или пользовательской «Factory Factory». 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 конфигурации, может использовать configSource атрибут, чтобы указать путь для конфигурации: http://weblogs.asp.net/cibrax/archive/2007/07/24/configsource-attribute-on-system-servicemodel-section.aspx

источник

2009-02-02 13:35:59 Daniel

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

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

источник

2009-02-02 13:57:59 AlexDrenea

точно - если у вас есть DLL, размещенная/используемая приложением, будет иметь значение только конфигурация приложения. Это основное решение для .NET. Именно поэтому настройки в отдельном app.config DLL проекта будут не использовать AT ALL .... :-( –

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

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

источник

2009-02-02 14:10:22

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

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

источник

2013-01-11 00:10:53 Rajiv

Есть 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();

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

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

Это обсуждается в MSDN documentation.

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

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

Пабло Cibraro показывает хороший пример этого здесь : Getting WCF Bindings and Behaviors from any config source

источник

2013-04-16 19:14:46 Philippe

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

ответ

Смежные вопросы