Использование веб-службы из .NET DLL - проблема app.config - PullRequest
Новая
       16

Использование веб-службы из .NET DLL - проблема app.config

10 голосов
/ 12 февраля 2010

Я создаю DLL, назовем ее mydll.dll , и в ней мне иногда нужно вызывать методы из веб-сервиса, 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 in.

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

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

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

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

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

Спасибо
Асаф

Ответы [ 4 ]

4 голосов
/ 12 февраля 2010

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

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

2 голосов
/ 22 апреля 2010

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

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

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

0 голосов
/ 12 февраля 2010

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

0 голосов
/ 12 февраля 2010

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

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

...