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

Я создаю 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.

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

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

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

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

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

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


person Asaf R    schedule 12.02.2010    source источник


Ответы (4)


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

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

person Restuta    schedule 12.02.2010
comment
Я скопирую конфигурацию вручную и добавлю то, что вы рекомендовали позже. Спасибо! - person Asaf R; 12.02.2010

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

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

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

person D.H.    schedule 22.04.2010

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

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

person Pablo Castilla    schedule 12.02.2010

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

person mythz    schedule 12.02.2010