Потребление webservice из .NET DLL - проблема app.config

Я создаю DLL, позволю называть его mydll.dll, и мне иногда приходится вызывать методы из webservice, myservice. mydll.dll построен с использованием С# и .NET 3.5.

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

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

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

Я рассмотрел несколько возможных подходов к атаке этой проблемы:

  • Вручную скопируйте конечные точки и привязки из mydell app.config в целевой файл EXE или веб файл .config.
    Пары модулей, не гибкие
  • Включить конечные точки и привязки из mydll app.config в target.config, используя configSource (см. здесь). Также добавьте связь между модулями
  • Программно загружать mydll app.config, читать конечные точки и привязки и создавать экземпляры Binding и EndpointAddress.
  • Используйте другой инструмент для создания локального интерфейса для myservice

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

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

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

ОТВЕТЫ

Ответ 1

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

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

Ответ 2

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

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

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

Ответ 3

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

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

Ответ 4

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