Используйте веб-сервис от DLL.NET - 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 разовьется, который является, почему я разъединился, это - funcionality от остальной части моей системы для начала. Во время той эволюции это, вероятно, добавит больше веб-сервиса, в который это будет звонить, исключая ручную вставку копии способы преодолеть эту проблему.

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

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

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

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

Спасибо,
Asaf

10
задан Asaf R 12 February 2010 в 08:17
поделиться

4 ответа

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

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

4
ответ дан 4 December 2019 в 03:16
поделиться

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

0
ответ дан 4 December 2019 в 03:16
поделиться

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

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

0
ответ дан 4 December 2019 в 03:16
поделиться

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

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

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

2
ответ дан 4 December 2019 в 03:16
поделиться
Другие вопросы по тегам:

Похожие вопросы: