Управление зависимостями системы контроля версий в Visual Studio Team System - Использование Веб-сервисов

Written on . Posted in Разработка и тестирование

ОГЛАВЛЕНИЕ

Страница 5 из 6

Использование Веб-сервисов

В более простых системах, в которых все проекты системы располагаются в одном групповом проекте, все разработчики, в конце концов, работают с локальными рабочими копиями всех Веб-сервисов, потому что они определены проектами Visual Studio в групповом проекте. Все проекты (включая все Веб-сервисы) устанавливаются локально при первом открытии решения из системы контроля версий. Аналогично, если Веб-сервис добавляется в решение одним из разработчиков, у всех остальных он устанавливается при следующем обновлении. При таком сценарии нет необходимости публиковать Веб-сервисы на центральном Веб-сервере среды коллективной разработки.

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

Более подробно об этом рассказывается в разделах «Рекомендации по работе с системой контроля версий» и «Практики работы с системой контроля версий» данного руководства.

Использование динамических URL для ссылки на Веб-сервисы

Если требуется вызвать Веб-сервис, необходимо сначала добавить в проект Веб-ссылку. При этом создается прокси-класс, посредством которого осуществляется взаимодействие с Веб-сервисом. Код прокси-класса изначально содержит статический Универсальный указатель ресурса (Uniform Resource Locator, URL) Веб-сервиса, например, http://localhost или http://SomeWebServer.

Важно: Для Веб-сервисов текущего решения, которое выполняется на вашем компьютере, должен использоваться только http://localhost, а не http://MyComputerName. Это гарантирует, что ссылка останется достоверной на всех компьютерах.

Обычно в прокси-классе используется статический URL. В среде производственной эксплуатации или тестирования, как правило, необходим другой URL. Существует три варианта решения этой проблемы:

  • Можно задавать URL Веб-сервиса программно при создании экземпляра прокси-класса.
  • Более гибкий подход без жесткого кодирования URL в прокси-классе – задать свойству URL Behavior (Поведение URL) ссылки на Веб-сервис значение Dynamic (Динамический). Такой подход является предпочтительным. Когда этому свойству задается значение Dynamic, в прокси-класс добавляется код для извлечения URL Веб-сервиса из специальной секции конфигурационного файла приложения (Web.config для Веб-приложения или SomeApp.exe.config для приложения Windows).
  • Также можно создать прокси-класс с помощью инструмента командной строки WSDL.exe, задавая ключ /urlkey. При этом подобно заданию значения свойства URL Behavior, в прокси добавляется код для извлечения URL Веб-сервиса, только в этом случае URL хранится в секции <applicationSettings> конфигурационного файла приложения.

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

Как использовать динамические URL и пользовательский конфигурационный файл

Чтобы добиться максимальной гибкости конфигурации, как в среде разработки, так и в среде производственной эксплуатации, свойству URL Behavior ссылки на Веб-сервис должно быть задано значение Dynamic. При добавлении Веб-ссылки Visual Studio по умолчанию присваивает этому свойству значение Dynamic. Чтобы проверить значение данного свойства:

  1. В Solution Explorer разверните список Веб-ссылок.
  2. Пройдитесь по всем Веб-ссылкам списка.
  3. Для каждой Веб-ссылки проверьте значение свойства URL Behavior (оно должно быть Dynamic).

Чтобы задать URL Веб-сервиса в пользовательском конфигурационном файле:

  1. Когда Веб-ссылка задается впервые, Visual Studio автоматически создает файл App.config, в котором содержится ссылка на Веб-сервис. Настройки конфигурации в файле App.config выглядят следующим образом:
<configuration>
  <configSections>
    <sectionGroup name="applicationSettings" type="System.Configuration.ApplicationSettingsGroup, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" >
      <section name=" YourProject.Properties.Settings" type="System.Configuration.ClientSettingsSection, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" requirePermission="false" />
    </sectionGroup>
  </configSections>
  <applicationSettings>
    <YourProject.Properties.Settings>
      <setting name="SomeService_ localhost _Service" serializeAs="String">
        <value>http://localhost/someservice/Service.asmx</value>
      </setting>
      </YourProject.Properties.Settings>
  </applicationSettings>
</configuration>

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

Также Visual Studio помещает в код, сформированный для этого прокси, значение URL по умолчанию. Это значение находится в файле Settings.Designer.cs. Чтобы увидеть этот файл:

  1. В Solution Explorer щелкните Веб-сервис правой кнопкой мыши.
  2. Выберите View in Object Browser (Просмотр в браузере объектов). В Object Browser найдите запись YourProject.Properties, где YourProject – имя проекта, содержащего ссылку на Веб-сервис.
  3. Разверните YourProject.Properties и щелкните двойным щелчком Settings (Настройки). При этом откроется файл Settings.Designer.cs, содержащий подобную строку: 
    [global::System.Configuration.DefaultSettingValueAttribute("http://localhost:/webservice/Service.asmx")]
    Это значение по умолчанию, используемое как URL Веб-сервиса, если не найдена информация о конфигурации.

Часто возникает необходимость изменить URL вызываемого Веб-сервиса. Например, требуется протестировать приложение с использованием Веб-сервиса, выполняемого локально на компьютере разработчика, или версии Веб-сервиса, выполняющейся в среде тестирования. Также очень часто URL Веб-сервиса производственной эксплуатации отличается от URL, используемого при разработке. Поэтому значение URL должно быть задано в пользовательском конфигурационном файле, на который будет ссылаться основной файл App.config. Имя пользовательского конфигурационного файла выбирается произвольно. В следующем примере используется имя User.config, чтобы было ясно, что это файл с конфигурацией пользователя.

Этапы создания файла User.config:

  1. В Solution Explorer щелкните правой кнопкой мыши проект, содержащий ссылку на Веб-сервис, выберите Add и затем щелкните New Item (Новый элемент).
  2. Выберите Application Configuration File (Конфигурационный файл приложения), измените имя на User.config и щелкните Add.
  3. Скопируйте настройки элемента <YourProject.Properties.Settings> из конфигурационного файла приложения (App.config) в файл User.config. Этот файл должен содержать только элемент, который выносится из основного конфигурационного файла приложения. Удалите директиву <?xml> и элемент <configuration>, если они присутствуют, как показано в следующем примере 
    <YourProject.Properties.Settings>
      <setting name="SomeService_localhost_Service" serializeAs="String">
        <value>http://localhost/someservice/Service.asmx</value>
      </setting>
    </YourProject.Properties.Settings>

Каждый разработчик должен задать содержимое своего файла User.config, чтобы использовать соответствующий URL. После этого необходимо указать системе конфигурации, что она должна получать данные конфигурации из файла User.config, а не файла App.config. Для этого файл App.config необходимо обновить следующим образом:

  1.  Добавьте атрибут configSource="user.config" в элемент <YourProject.Properties.Settings> главного конфигурационного файла приложения. Тем самым, получив информацию из этой секции, среда выполнения будет перенаправлена в указанный пользовательский конфигурационный файл.
  2. Удалите содержимое элемента <YourProject.Properties.Settings>.

Теперь App.config должен выглядеть следующим образом: 

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <configSections>
    <sectionGroup name="applicationSettings" type="System.Configuration.ApplicationSettingsGroup, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" >
      <section name="YourProject.Properties.Settings" type="System.Configuration.ClientSettingsSection, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" requirePermission="false" />
    </sectionGroup>
  </configSections>
  <applicationSettings>
    <yourProject.Properties.Settings configSource="user.config">
      </YourProject.Properties.Settings>
    </applicationSettings>
</configuration>

В предыдущем примере YourProject – имя проекта, содержащего ссылку на Веб-сервис.

Важно: Если используется атрибут configSource, пользовательский конфигурационный файл должен присутствовать и содержать всего один элемент, <YourProject.Properties.Service>. Также необходимо гарантированно удалить XML-содержимое элемента <YourProject.Properties.Service> при добавлении атрибута configSource=”user.config”.

При использовании User.config:

  • Убедитесь, что развертывание файла User.config происходит вместе с кодом приложения. Для этого в Solution Explorer щелкните правой кнопкой мыши файл User.config, выберите опцию Properties и задайте свойству Copy To Output Directory (Копировать в выходной каталог) значение Copy if newer (Копировать, если это более свежая версия).
  • Не добавляйте свой файл User.config в систему контроля версий. Так каждый разработчик и группа тестирования могут явно привязываться к определенным URL, используя собственные файлы User.config. В системе контроля версий могут располагаться другие файлы User.config, например, используемые для тестирования и производственной эксплуатации. Эти файлы должны обслуживаться пользователями, ответственными за управление средами тестирования и производственной эксплуатации. Файлы User.config для тестирования и производственной эксплуатации не должны храниться как часть проектов Веб-сервиса, они должны располагаться в других областях системы контроля версий.
  • Храните глобальный файл User.config в системе контроля версий. Он может содержать только корневой элемент (без элемента <setting>) или может определять местоположение Веб-сервиса по умолчанию. Наличие файла User.config обеспечивает возможность работы системы конфигурации.

Подсказка: По умолчанию пользовательский конфигурационный файл автоматически добавляется в систему контроля версий при добавлении решения. Чтобы предотвратить это, при первой регистрации изменений в файле необходимо убрать флажок напротив файла User.config. После этого можно щелкнуть правой кнопкой мыши файл в Solution Explorer и выбрать опцию Undo Pending Changes (Отменить ожидающие регистрации изменения). Тогда файл гарантированно не будет подлежать контролю версий.

Важно: Если в файле User.config, задающем URL, имеется только корневой элемент, и нет элемента настроек, прокси-класс Веб-сервиса использует URL по умолчанию, который указан в файле Settings.Designer.cs. Это значение определено как атрибут DefaultValueSettings (Значения по умолчанию) и выглядит следующим образом 

[global::System.Configuration.DefaultSettingValueAttribute("http://localhost/webservice/Service.asmx")]

Важно: Для Веб-приложений, использующих пользовательский конфигурационный файл, любые изменения этого файла по умолчанию приводят к автоматическому перезапуску Веб-приложения. Чтобы отменить перезапуск приложения при изменении значения, необходимо добавить атрибут restartOnExternalChanges="false" (перезапустить при внешних изменений) в описание секции конфигурационного файла, как это сделано ниже: 

<configSections>
  <sectionGroup name="applicationSettings" type="System.Configuration.ApplicationSettingsGroup, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">
    <section name="Test.Properties.Settings" type="System.Configuration.ClientSettingsSection, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" requirePermission="false" restartOnExternalChanges="true"/>
  </sectionGroup>
</configSections>

Если этот атрибут добавлен в секцию конфигурации файла Web.config, изменения внешнего конфигурационного файла User.config не приводят к автоматическому перезапуску Веб-приложения. Однако эти изменения по-прежнему отражаются в приложении.

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

форум программирование