Потребляйте WebService из .NET DLL - app.config проблема

Question

Я строю DLL, давайте назовем его MyDll.dll, и в нем я иногда нужно вызывать методы из WebService, MyService. mydll.dll построен с использованием C# и .NET 3.5.

Употреблять MyService от MyDLL Я добавил службу в Visual Studio 2008, который является более или менее такой же, как с помощью svcutil.exe. Это создает класс, который я могу создать, и добавляет конфигурации конечных точек и привязок к mydll app.config.

Проблема в том, что mydll app.config не загружается. Вместо того, что заряжено является app.config или web.config программы я использую MyDLL в.

Я ожидаю MyDLL развиваться, поэтому я развязан это funcionality от остальной части моей системы начать с. Во время этой эволюции он, скорее всего, добавит больше webservice, на которые он будет звонить, исключая способы ручной копирования и вставки для решения этой проблемы.

Я смотрел несколько возможных подходов к атакующим этому вопросу:

1. вручную скопировать конечные точки и привязки из mydell app.config целевой EXE или веб-файл .config.
   Пары в модули, а не гибкие
2. Включить конечные точки и привязки из MyDLL app.config в целевом .config, используя configSource (см here). добавить также связь между модулями
3. Программной нагрузкой MyDLL app.config, чтение и конечных точками привязки, и создать экземпляр привязки и EndpointAddress.
4. Используйте другой инструмент для создания локального фронтэнда для MYSERVICE

Я не уверен, в какую сторону идти. Вариант 3 звучит многообещающе, но, как выясняется, много работы и, вероятно, представит несколько ошибок, поэтому он с сомнением окупается. Я также не знаком ни с каким другим инструментом, кроме канонического svcutil.exe.

Просьба либо предоставить за и против, как вышеперечисленные альтернативы, предоставить советы по реализации любого из них или предложить другие подходы.

Спасибо,
Асаф

Answer 1

Я предпочитаю вариант 5 - «В конфигурации кода», да, да, вы теряете возможность изменения без перекомпиляции, но в зависимости от того, что вам нужно. Если вы знаете, что вы никогда не измените свои конечные точки или не измените его редко - просто выполните свою конфигурацию в коде, вы получите проверку времени компиляции в качестве бонуса =) This и this могут помочь.

И кстати, конфигурация клиента конфиги является общий случай, если у вас есть много этих клиентов это может быть боль, и вы должны думать о 3 или 5 =)

Answer 2

я должен идти от варианта 1 или 2 (для меня это один лучше). Модули связаны в dll, поэтому они уже соединены. Изменение конфигурации тривиально, но создание инфраструктуры для чтения вас еще больше скроет.

3 и 4 опции - это намного больше работы.

Answer 3

Я собрал мой open source web services framework вниз также и с одной dll. Хотя я использовал совершенно другой подход, я создал общий IHttpHandler для конечных точек JSON и XML (и общую конфигурацию WCF для конечных точек SOAP), которые могут обрабатывать каждый запрос. Таким образом, моя конфигурация - простой однострочный для всех моих веб-сервисов, сопоставляющих конечную точку с моим обработчиком, который находится в файле хоста .config приложения (например, ASP.NET Web.config или Console App.config), где он предназначен для быть.

Answer 4

Вы можете использовать svcutil в качестве события post-build в приложении, которое потребляет DLL. Как это:

svcutil.exe <service_address> /config:$(TargetPath).config /mergeConfig 

Это будет объединять необходимые конфигурации в yourapp.exe.config. Если вы добавите новую ссылку на службу в DLL, вам придется добавить еще одну строку здесь, поэтому она не полностью автоматическая, но все же немного проще, чем вручную копировать конфигурацию.