Проблемы с привязкой Visual Studio BasicHttpBinding и конечной точкой

Question

У меня есть приложение WPF в версии 2008 с некоторыми ссылками на веб-службы.По разным причинам (максимальный размер сообщения, методы аутентификации) Мне нужно вручную определить ряд настроек в app.config клиента WPF для привязок служб.

К сожалению, это означает, что когда я обновляю ссылки на службы в проекте, мы получаем беспорядок - несколько привязок и конечных точек.Visual Studio создает новые привязки и конечные точки с числовым суффиксом (т.Е. "Service1" как дубликат "Service"), что приводит к недопустимой конфигурации, поскольку для каждой ссылки на службу в проекте может быть только одна привязка.

Это легко продублировать - просто создайте простой ASP "Hello World".Веб-служба Net и приложение WPF в решении измените MaxBufferSize и maxReceivedMessageSize в привязке app.config, а затем обновите ссылку на службу.

На данный момент мы работаем над этим, просто отменив проверку в app.config после обновления ссылок, но я не могу не думать, что должен быть лучший способ!

Кроме того, настройки, которые нам нужно изменить вручную, следующие:

<security mode="TransportCredentialOnly">
    <transport clientCredentialType="Ntlm" />
</security>

и:

<binding maxBufferSize="655360" maxReceivedMessageSize="655360" />

Мы используем класс service factory, поэтому, если эти параметры каким-то образом можно установить программно, это сработает, хотя свойства, похоже, не отображаются.

Answer 1

Создайте a .Bat-файл, который использует svcutil для генерации прокси, с настройками, подходящими для вашего проекта.Это довольно просто.Нажав на batfile, легко генерировать новые прокси-файлы всякий раз, когда интерфейс был изменен.

Затем пакет может быть использован в автоматизированных сборках.Затем вам нужно настроить app.config (или web.config) только один раз.Обычно мы разделяем различные конфигурации для разных сред, таких как dev, test prod.

Пример (следите за перерывами на линии):

REM generate meta data
call "SVCUTIL.EXE" /t:metadata "MyProject.dll" /reference:"MyReference.dll"

REM making sure the file is writable
attrib -r "MyServiceProxy.cs"

REM create new proxy file
call "SVCUTIL.EXE" /t:code *.wsdl *.xsd /serializable /serializer:Auto /collectionType:System.Collections.Generic.List`1  /out:"MyServiceProxy.cs" /namespace:*,MY.Name.Space /reference:"MyReference.dll" 

:)

//W

Answer 2

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

Answer 3

Почему-то я предпочитаю использовать svcutil.exe напрямую, чем использовать функцию "Добавить ссылку на службу" Visual Studio:P Это то, что мы делаем в наших проектах WCF.

Answer 4

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

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

В любом случае, спасибо за совет.

Answer 5

Что мы делаем, так это извлекаем (из системы управления версиями) файлы app.config и * .cs, которые автоматически генерируются утилитой svcutil.exe, затем мы запускаем пакетный файл, который запускается svcutil.exe для извлечения метаданных службы.Когда это будет сделано, мы перекомпилируем код, убедимся, что он работает, затем вернем обновленные файлы app.config и * .cs обратно.Это намного надежнее, чем использование часто глючащего "Добавить ссылку на службу" в Visual Studio.