Опубликован: 25.03.2010 | Уровень: специалист | Доступ: платный
Лекция 6:

Управление зависимостями в системе управления исходным кодом Visual Studio Team System

< Лекция 5 || Лекция 6: 123 || Лекция 7 >

Ссылки на веб-службы

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

В более крупных системах веб-службы могут быть опубликованы на вебсервере с централизованным доступом при помощи IIS (Internet Information Server) . В локальной установке веб-служб нуждаются не все разработчики. Они могут получить доступ к нужной веб-службе из своих клиентских проектов, но для этого потребуется соответствующим образом настроить ссылку.

Используйте в ссылках на веб-службы динамические URL /

Если вы хотите обращаться к веб-службе, необходимо добавить в ваш проект ссылку на нее. При этом генерируется прокси-класс, посредством которого вы взаимодействуете с веб-службой. Код прокси изначально содержит статические URL веб-служб, например, http://localhost или http://SomeWeb-Server.

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

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

  • Программно установить URL веб-службы во время создания экземпляра прокси-класса.
  • Задать для свойства URL Behavior ссылки на веб-службу значение Dynamic. Это предпочтительный способ. При установке для свойства значения Dynamic в прокси-класс добавляется код, извлекающий URL веб-службы из пользовательского раздела файла конфигурации приложения - Web.config для веб-приложения или SomeApp.exe.config для приложений Windows.
  • Сгенерировать прокси с помощью инструмента командной строки WSDL. exe, задав параметр /urlkey При этом происходит примерно то же самое, что и при установке свойства URL Behavior, но в этом случае URL хранится в разделе <applicationSettings> файла конфигурации приложения. Использование динамического URL позволяет создавать пользователь ский файл конфигурации, который будет перекрывать основной файл конфигурации приложения. Это дает разработчикам и членам группы тестирования возможность временно перенаправить ссылку веб-службы в другое расположение.

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

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

  1. В обозревателе Solution Explorer разверните список веб-ссылок.
  2. Выделите по очереди каждую ссылку из списка.
  3. Убедитесь, что свойству URL Behavior присвоено значение Dynamic. При первом добавлении ссылки Visual Studio автоматически генерирует файл App.config. Этот файл содержит ссылку на веб-службу и параметры конфигурации. Он выглядит примерно так:
<configuration> 
 <configSections>
  <sectionGroup name="applicationSettings" type="System.Configuration. 
     ApplicationSettingsGroup, System, Version=2.0.0.0, Culture=neutral, 
       PublicK eyToken=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>lhttp://localhost/someservice/Service.asmx</value> </setting>   
   </YourProject.Properties.Settings^gt; 
 </applicationSettings> 
</configuration>

В этом файле есть новый раздел конфигурации, используемый прокси-классом. В нем содержится стандартный адрес веб-службы, заданный 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.

  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,
            PublicK eyToken=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.Setting> </applicationSettings> 
      </configuration>

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

важно! Если вы задали атрибут configSource, пользовательский файл конфигурации обязательно должен существовать и содержать только элемент <YourProject.Properties.Settings>. Добавляя атрибут config Source ="user.config" в основной файл конфигурации, не забудьте удалить из элемента <YourProject.Properties.Settings> содержимое XML.

Используя файл 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 содержит только корневой элемент и в нем нет элемента <setting>, прокси-класс веб-службы использует стандартный URL, указанный в файле Settings. Designer.cs. Это значение определяется атрибутом DefaultValueSettings и выглядит так:

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

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

<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" 
  requirePermissio n="false" restartOnExternalChanges="true"/>
 </sectionGroup> 
</configSections>

Если вы добавите этот атрибут в раздел configuration файла Web.config, изменения во внешнем файле User.config не будут приводить к перезапуску веб-приложения, но будут ему видны.

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

Ссылки на базы данных

Ссылками на базы данных в форме строк подключения также можно управлять при помощи внешнего файла конфигурации. Преимущество данного способа состоит в том, что каждый разработчик может легко задать строку подключения в собственном файле конфигурации User.config. Изменения, внесенные одним разработчиком, например, перенаправление подключения в локальную БД для модульных тестов, не затронут остальных разработчиков.

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

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

Строки подключения в файлах конфигурации

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

Чтобы использовать пользовательский файл конфигурации для хранения связывающих строк, выполните следующие действия:

  1. Добавьте атрибут configSource="user.config" в элемент <connectionStrings> главного файла конфигурации приложения.

    <configuration<
      <connectionStrings configSource="user.config"/> 
    </configuration>
  2. Чтобы перекрыть настройки из главного файла конфигурации приложения, создайте файл User.config в той же папке, что и файл конфигурации приложения. Добавьте в него элемент <connectionStrings<. Обратите внимание, что приведенная далее строка подключения ссылается на локальную базу данных.

    <connectionStrings<
     <add name="DBConnStr" connectionString="server=localhost;
       Integrated Security=SSPI;database=Accounts"/> 
     </connectionStrings>
  3. Внутри проекта используйте следующий код для получения строки подключения из пользовательского файла конфигурации. В нем использовано статическое свойство ConnectionStrings класса System.Configuration. ConfigurationManager. В приложении WinForm вы должны явно добавить ссылку на System.Configuration.dll.

    using System.Configuration;
    private string GetDBaseConnectionString() 
    {
      return ConfigurationManager.ConnectionStrings["DBConnStr"]. 
        ConnectionString; 
    }
  4. Убедитесь, что развернули файл User.config вместе с кодом приложения. Это делается в обозревателе Solution Explorer. Щелкните правой кнопкой файл User.config, выберите команду Properties и присвойте свойству Copy To Output Directory значение Copy if newer.

Не добавляйте файл User.config в систему управления исходным кодом. При этом каждая группа разработчиков и тестировщиков сможет использовать собственную строку подключения к БД, задав его в собственном файле User.config. Система управления исходным кодом может содержать другие файлы User.config, например, для тестирования и промышленного использования, управление которыми должно осуществляться пользователями, ответственными за соответствующие среды. Эти файлы User.config следует хранить не в составе проектов БД, а в других областях системы управления исходным кодом.

В системе управления исходным кодом должен иметься файл User.config для каждой из используемых сред, например, производственной и тестовой, с указанием строки подключения к соответствующей БД.

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

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

Резюме

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

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

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

Дополнительные ресурсы

< Лекция 5 || Лекция 6: 123 || Лекция 7 >
Илья Макаренко
Илья Макаренко

Добрый день.

Вопрос №1

Какова стоимость получения диплома о мини-МБА по данному курсу? Или ориентироваться на указанную на сайте?

Вопрос №2

Возможно ли начать обучение без потери результатов, не отправив документы на зачисление, а отправку выполнить позже?

Александр Медов
Александр Медов

Здравствуйте, какова полная сумма предоставленной услуги с печатью документа и отправкой по почте?

Евгений Летенков
Евгений Летенков
Россия, Москва, РУДН, 2005
Алексей Корзинин
Алексей Корзинин
Россия