Аннотация

В этой главе рассказывается, как работать с Web-ссылками, а также со ссылками на сборки, базы данных и COM-объекты.

Это глава 4 руководства по групповой разработке в среде Visual Studio^® .NET и Visual SourceSafe^™. Чтобы получить полное представление о данном руководстве, начните отсюда.

Информация в этой главе поможет вам:

• управлять зависимостями и ссылками, связывающими проекты и решения;
• работать со ссылками на .NET-сборки, Web-сервисы, базы данных, обслуживаемые компоненты (serviced components) и библиотеки COM Interop.

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

Например, при изменении какого-либо модуля, от которого зависят другие сборки, вы должны заново собрать клиентские сборки, чтобы они соответствовали последней версии этого модуля. В зависимости от типа модуля и того, как на него ссылаются, Microsoft^® Visual Studio^® .NET может автоматически определить, в каком порядке следует собирать приложение.

Ссылки на сборки

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

Использование ссылок на проекты

В диалоговом окне Add Reference на вкладке Projects перечисляются остальные проекты текущего решения. Здесь можно создать ссылку из данного проекта на другой проект в том же решении. Использование таких ссылок является рекомендуемым способом обращения к другим сборкам и дает много преимуществ.

Примечание Ссылки на проекты - главная причина, по которой следует по возможности всегда применять модель на основе одного решения (single soluton model) или одного решения, разбитого на части (partitioned single soluton model).

Преимущества ссылок на проекты

Ссылки на проекты дают следующие преимущества.

• Работают на всех компьютерах, на которые загружены решение и его проекты. Это объясняется тем, что в файл проекта помещается GUID (Globally Unique Identifier), уникально идентифицирующий в контексте текущего решения проект, на который имеется ссылка.
• Позволяют Visual Studio .NET отслеживать зависимости проекта и определять правильный порядок его сборки.
• Не допускают отсутствия на данном компьютере сборок, на которые есть ссылки.
• Обеспечивают автоматическое отслеживание изменений в конфигурации проекта. Например, если вы собираете решение в отладочной конфигурации, ссылки указывают на отладочные сборки (assemblies), генерируемые для этих проектов, а если вы собираете решение в финальной конфигурации - на конечные версии сборок. То есть вы можете автоматически переключаться с отладочной конфигурации на финальную, ничего не меняя в ссылках.
• Позволяют Visual Studio .NET выявлять и предотвращать круговые зависимости (circular dependencies).

Используйте файловые ссылки только при необходимости

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

• Чтобы сослаться на сборку .NET Framework, выберите ее из списка на вкладке .NET диалогового окна Add References.
• Найдите нужную сборку, нажав кнопку Browse в диалоговом окне Add Reference.

Если вы создаете файловую ссылку, путь к сборке запоминается в файле проекта с контролируемым исходным кодом (source controlled project file). Для локальных сборок хранится относительный путь, а для сборок, размещаемых на серверах, - полный сетевой путь (см. фрагмент кода ниже). Обратите внимание на атрибуты HintPath.

<References>

  <Reference

     Name = "System.XML"

     AssemblyName = "System.Xml"

     HintPath =   "..\..\..\..\WINDOWS\Microsoft.NET\Framework\v1.0.3423\System.XML.dll"

  />

  <Reference

    Name = "Lib1"

    AssemblyName = "Lib1"

    HintPath = \\BuildServer\Latest\Release\SharedComponent\SomeControl.dll

  />

</References>

Примечание Сборки наподобие System.XML.dll размещаются в кэше глобальных сборок (Global Assembly Cache, GAC). Однако ссылки никогда не указывают непосредственно на сборки в GAC. Когда вы выбираете сборку на вкладке .NET диалогового окна Add References, на самом деле создается ссылка на копию сборки, находящуюся в папке %windir%\Microsoft.NET\Framework\<version>\.

Указывайте для ссылок на проекты и файлы copy local = true

С каждой ссылкой связывается атрибут copy local. При добавлении ссылки Visual Studio .NET автоматически определяет начальное значение этого атрибута (true или false). Атрибут получает значение false, если ссылка указывает на сборку, копия которой должна содержаться в GAC, и true в ином случае.

Не изменяйте значение этого атрибута по умолчанию. Когда атрибут copy local равен true, Visual Studio .NET копирует сборку, задаваемую ссылкой (и любые другие, от которых зависит эта сборка), в выходную папку клиентского проекта.

Например, если клиентский проект ссылается на сборку Lib1, а Lib1 зависит от Lib2 и Lib3, Visual Studio .NET при сборке проекта автоматически копирует Lib1, Lib2 и Lib3 в локальную выходную папку этого проекта.

Автоматическое отслеживание зависимостей

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

Ссылки на проекты в системах на основе одного решения или одного решения, разбитого на части

По возможности старайтесь использовать ссылки на проекты, а не файловые ссылки.

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

1. Сборки .NET Framework, ссылки на которые задаются на вкладке .NET диалогового окна Add References. В среде групповой разработки такие сборки не создают проблем, так как на всех компьютерах они находятся в общем для всех проектов месте.
2. Сборки внешних систем (outer system assemblies), подключаемые в диалоговом окне Add References с помощью кнопки Browse. К ним относятся компоненты сторонних поставщиков и сборки, созданные в вашей компании, но не входящие в состав текущей системы. О том, как управлять этим типом сборок, см. в разделе Включение сборок внешних систем в проекты.

Файловые ссылки в системах на основе нескольких решений

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

Выбор местонахождения сборок, на которые имеются ссылки

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

• Создать ссылку на сборку, которая находится на сервере сборок, указав либо букву виртуального диска, либо UNC-путь (Universal Naming Convention).
• Скопировать группу сборок, генерируемых сборочным процессом, с сервера сборок на локальный компьютер и создать локальную ссылку, указав букву виртуального диска. О применении виртуальных дисков см. в разделе Используйте виртуальный диск для большей гибкости.

Преимущества создания ссылок на сборки, хранящиеся на сервере сборок

Такой подход дает следующие преимущества.

• Ссылки гарантированно указывает на последнюю версию сборок, так как эти сборки регулярно (например, ежедневно) обновляются в сборочном процессе.
• Пути в ссылках, содержащие буквы виртуальных дисков или UNC-пути, можно использовать на всех компьютерах разработчиков и на сервере сборок.

Недостатки создания ссылок на сборки, хранящиеся на сервере сборок

У этого подхода есть ряд недостатков, которые могут оказаться существенными в некоторых средах групповой разработки (особенно в больших). Вот некоторые из этих недостатков.

• У вас нет прямого контроля над тем, в какой именно момент обновляются сборки, на которые вы ссылаетесь. В результате возможна ситуация, при которой новая версия сборки создается на сервере в самый неподходящий момент, например в то время, когда вы занимаетесь разработкой и отладкой другого модуля системы. Хотя централизованный сборочный процесс обычно запускается по ночам, промежуточные версии сборок иногда создаются и в рабочее время. Генерация промежуточных версий может вызвать проблемы.
• Не поддерживается разработка в автономном (изолированном) режиме. Вам необходимо прямое соединение с сервером сборок всякий раз, когда вы собираете локальный проект, ссылающийся на сборки на сервере.

Изолированная разработка

Если при разработке нужен высокий уровень изоляции, ведите изолированную разработку приложения. Для реализации такого подхода требуются следующие действия.

1. Скопируйте выходные сборки с сервера сборок в какой-либо стандартный каталог на своем компьютере. Это можно делать вручную или с помощью сценария (script).
2. Создайте общедоступный виртуальный диск (например диск R), чтобы все разработчики могли ссылаться на сборки, указывая один и тот же путь.
3. Установите ссылки на локальные сборки, указав в путях к ним букву этого виртуального диска (диска R).
4. Периодически проверяйте, не появились ли на сервере новые версии сборок, и вручную копируйте их на локальный компьютер.

Используйте виртуальный диск для большей гибкости

Если вы ссылаетесь на локальную сборку, скопированную с сервера сборок, то должны создать виртуальный диск и указывать букву этого диска, используя команду subst.

Внимание Все разработчики группы должны использовать одну и ту же букву диска, так как она хранится в файле проекта с контролируемым исходным кодом (source controlled project file), как показано в следующем фрагменте кода.

<References>

  <Reference

    Name = "Lib1"

    AssemblyName = "Lib1"

    HintPath = "R:\Latest\Release\SharedComponent\SomeControl.dll"

  />

</References>

Еще одно преимущество использования буквы виртуального диска - возможность легко сопоставить ее с другим путем. Например, большую часть времени буква виртуального диска может быть сопоставлена с путем к серверу сборок, а на какое-то время, когда нужно поработать изолированно, - с локальным путем.

Создавая файловые ссылки, всегда указывайте финальные версии сборок

Сценарий сборки регулярно (обычно ежедневно) обновляет сборки, хранящиеся на сервере, до текущих версий. Как правило, сценарий сборки генерирует отладочные и финальные версии сборок. Разработчики используют отладочные DLL, а тестировщики - финальные. При этом применяется следующая схема.

• Как разработчик, вы устанавливаете себе отладочные варианты DLL, чтобы использовать их при разработке и тестировании модулей.
• Члены группы тестирования устанавливают финальную версию системы и всегда тестируют финальные версии DLL. Не затягивайте с генерацией финальной версии до наступления даты выпуска разрабатываемой вами системы, так как в финальной версии могут возникнуть проблемы, которых не было в отладочной.
  Для поддержки и отладочных, и финальных версий сборочный процесс копирует сборки в размещаемые на сервере сборок папки Release и Debug. Подробную информацию об этом см. в главе 5 "Сборочный процесс".
  Как разработчик, вы должны при создании ссылок всегда указывать сборки из папки Release. Это объясняется следующими причинами.
• Именно эти версии сборок, от которых зависит ваше приложение, в конечном итоге будут использоваться на практике.
• Вам никогда не понадобится переадресовывать файловые ссылки с папки Debug на папку Release, чтобы сгенерировать финальную версию. Файловые ссылки в отличие от ссылок на проекты не обновляются динамически при изменении конфигурации.

При изолированной разработке и отладке задавайте пути к ссылкам

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

1. Скопируйте решение на свой компьютер.
2. Соберите отладочную версию сборки.
3. Задайте в клиентском проекте путь к ссылкам, указывающий на отладочную выходную папку сборки, на которую ссылается ваш проект.
4. Заново соберите клиентский проект и запустите его. В результате в выходной папке клиентского проекта будет находиться локальная отладочная версия сборки, на которую ссылается ваш проект. Теперь можно приступить к отладке этой сборки в пошаговом режиме.
5. Когда вы завершите отладку и захотите вернуться к сборке, которую обычно используете, удалите запись пути к ссылкам.

Что такое путь к ссылкам?

Путь к ссылкам (reference path) - это параметр, который задавается индивидуально для каждого компьютера и каждого разработчика и который хранится в виде XML-элемента в файле пользовательских параметров проекта (*.csproj.user или *.vbproj.user). Путь к ссылкам помогает Visual Studio .NET находить сборки, на которые ссылается проект.

Внимание Если вы будете следовать приведенным выше рекомендациям и использовать для обращения к сборкам либо ссылки на проекты, либо файловые ссылки (с виртуальными дисками), то Visual Studio .NET на любом компьютере сможет напрямую разрешать все ссылки, и вам скорее всего не потребуется задавать пути к ссылкам. Однако путь к ссылкам иногда может оказаться полезным, так как позволяет переопределить путь, заданный элементом <HintPath> в файле проекта с контролируемым исходным кодом.

Разрешение ссылок на сборки при сборке проекта

Во время сборки Visual Studio .NET разрешает ссылки на сборки, выполняя поиск в следующих местах в указанном порядке.

1. В одной из папок проекта. Сборка будет там, если вы добавили ее в проект командой меню Add Existing Item. Папки проектов - любые папки, показываемые в Solution Explorer (если не установлен режим Show All Files).
2. В папках, заданных атрибутом ReferencePath элемента <Settings> в файле пользовательских параметров проекта. В этом атрибуте может содержаться список папок, разделенных запятыми.
3. По ссылкам из атрибута <HintPath> в файле проекта.
   В папках, заданных параметрами реестра. В этих папках хранятся сборки, показываемые на вкладке .NET диалогового окна Add references. Подробнее об этом см. в разделе Использование вкладки .NET диалогового окна Add Reference.
4. В подпапке obj папки проекта (поиск сборок COM Interop). Подробнее об этом см. в разделе Ссылки на COM-объекты.

Изолированная разработка и тестирование модулей

Путь к ссылкам удобен и в том случае, когда вы ведете изолированную разработку и тестируете модули систем, состоящих из нескольких решений. Например, рассмотрим два решения - SA и SB; допустим, в решении SA есть проект PA, зависимый от библиотечного проекта PB, входящего в состав решения SB. Если вам нужно вести изолированную разработку и протестировать модули этих двух решений перед сборкой следующей версии системы, вы можете сменить путь к ссылкам в проекте PA на выходную папку проекта PB. Тогда можно внести изменения в проект PB, заново собрать его на локальном компьютере и тестировать PB, обращаясь к нему из решения SA.

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

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

Как задать путь к ссылкам для определенного проекта

Для установки в определенном проекте пути к ссылкам выполните следующие действия.

Чтобы сменить путь к ссылкам в данном проекте

1. В Solution Explorer щелкните проект правой кнопкой мыши, а затем выберите Properties.
2. Раскройте папку Common Properties и щелкните Reference Path.
3. Для проектов на C#: щелкните значок New Line и введите новый путь к ссылкам.
   - или -
   Для проектов на Visual Basic .NET: введите путь к ссылкам в поле Folder и щелкните Add Folder.
4. Щелкните OK, чтобы закрыть диалоговое окно Properties.

Включение сборок внешних систем в проекты

Лучший способ работы с такими сборками (например, с Web-элементами сторонних поставщиков или с компонентами, не перекомпилируемыми вашим сборочным процессом) - напрямую включать их в проекты, которые на них ссылаются. В принципе со сборками внешних систем надо работать так же, как с файлами .bmp или .gif.

Как включить сборку внешней системы в проект и сослаться на нее

1. В Solution Explorer щелкните правой кнопкой мыши проект, в который вы хотите добавить ссылку на сборку, и выберите Add Existing Item.
2. Выберите нужную сборку и щелкните OK. Тогда сборка будет скопирована в папку проекта и автоматически добавлена в VSS (предполагается, что данный проект уже контролируется VSS).
3. Щелкните кнопку Browse в диалоговом окне Add Reference и установите ссылку на файл сборки в папке проекта.

Преимущества

Такой подход дает два преимущества.

• Сборки внешних систем находятся под контролем вместе с файлами проектов. Когда появляется новая версия сборки, ее можно добавить в VSS как новую версию файла со своей хронологией.
• Еще важнее, что VSS охватывает вашу систему в целом, вместе со всеми внешними сборками, например элементами управления от сторонних поставщиков. Из VSS можно получить любую предыдущую версию системы, в том числе ее исходный код и внешние модули, от которых она зависит. Благодаря этому вам доступен полный "снимок" более ранних версий системы.

Совместное использование сборок внешних систем в VSS

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

Эту проблему можно решить, настроив VSS на совместное использование сборки проектами, которые с ней работают. Тогда достаточно обновить файл сборки в одном из проектов. Чтобы актуализировать копии, используемые другими проектами, в Solution Explorer щелкните проект правой кнопкой мыши и выберите Get Latest Version (Recursive).

Использование вкладки .NET диалогового окна Add Reference

На вкладке .NET диалогового окна Add Reference показываются системные сборки и PIA-сборки (Primary Interop Assembly), входящие в состав .NET Framework, и, возможно, другие сборки. На этой вкладке обычно (но не обязательно) перечисляются сборки, установленные в GAC.

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

Например, можно изменить реестр так, чтобы его записи указывали имена папок со сборками, которые генерируются вашим сценарием сборки (локально или на сервере сборок). Тогда разработчики смогут ссылаться на эти сборки через вкладку .NET, не используя кнопку Browse.

Добавление на вкладку .NET собственных сборок

1. Создайте подраздел (например InnerSystemAssemblies) в одном из следующих разделов реестра:

   HKEY_LOCAL_MACHINE\Software\Microsoft\.NETFramework\AssemblyFolders
   HKEY_CURRENT_USER\Software\Microsoft\.NETFramework\AssemblyFolders
   

2. Задайте в этом разделе параметр по умолчанию с именем папки, содержащей ваши сборки.
3. Если вы открыли Visual Studio .NET, то, чтобы внесенные изменения вступили в силу, закройте эту среду и перезапустите.

Ссылки на Web-сервисы

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

Если же Web-сервисы входят в состав системы на основе нескольких решений, то не всем разработчикам нужно устанавливать Web-сервис локально.

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

Контроль версий Web-сервисов при разработке

Web-сервисы, используемые в процессе разработки, со временем модифицируются. Поэтому нужно следить за тем, чтобы на Web-сервере хранились последние версии этих сервисов.

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

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

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

Всегда используйте динамические URL

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

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

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

• Программно указывать URL Web-сервиса при создании экземпляра прокси-класса.
• Применить более гибкий подход, при котором URL не "зашивается" в прокси: указать для свойства URL Behavior ссылки на Web-сервис значение dynamic. Рекомендуется использовать именно такой подход. Когда свойству присваивается значение dynamic, в прокси-класс добавляется код, считывающий URL Web-сервиса из раздела <appSettings> файла конфигурации приложения - Web.config для Web-приложения или SomeApp.exe.config для Windows-приложения.

Кроме того, при динамическом задании URL можно указать пользовательский файл конфигурации, который переопределяет параметры, определенные в главном файле конфигурации приложения. Благодаря этому отдельные разработчики (и члены группы тестирования) могут временно переопределять ссылки на Web-сервис, указывая какой-либо другой URL.

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

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

1. Добавьте атрибут file="user.config" в элемент appSettings главного файла конфигурации приложения. После этого исполняющая среда при обращении к информации из раздела appSettings будет автоматически считывать параметры из пользовательского файла конфигурации. Если такого файла нет, берутся параметры из главного файла конфигурации приложения - ошибка периода выполнения не генерируется.

   <configuration>
    <appSettings file="user.config">
      <add key="ClientApplication.SomeServer.SomeService"
           value="http://ProdWeb/myXmlWebService/Service1.asmx"/>
    </appSettings>
   </configuration>
   

   В предыдущем примере ClientApplication.SomeServer.SomeService - полностью определенное имя прокси-класса Web-сервиса. ClientApplication.SomeServer - это пространство имен, а SomeService - имя прокси-класса.

2. Создайте файл User.config (в папке, где находится файл конфигурации приложения) и добавьте в него запись appSettings, содержащую пару "ключ-значение", которая идентифицирует URL Web-сервиса, как показано в следующем фрагменте кода. Обратите внимание, что в этом примере URL указывает на локальный Web-сервер, и, кроме того, в файле User.config нет элемента <configuration>.

   <appSettings>
      <add key="ClientApplication.SomeServer.SomeService"
           value="http://localhost/myXmlWebService/Service1.asmx"/>
   </appSettings>
   

3. Не ставьте файл User.config на контроль в VSS. Тогда каждый разработчик (или группа тестирования) сможет явно указывать используемый им URL в своем файле User.config. В главном файле конфигурации приложения следует задать адрес производственной версии Web-сервиса. Этот адрес используется, когда файл User.config отсутствует.
   Совет По умолчанию пользовательский? файл конфигурации автоматически добавляется в VSS. Чтобы этого избежать, в Solution Explorer щелкните файл правой кнопкой мыши и выберите Exclude From Project. Чтобы потом увидеть файл в Solution Explorer, щелкните значок Show All Files вверху окна Solution Explorer.
   Внимание Web-приложения, которые обращаются к пользовательскому файлу конфигурации, не учитывают автоматически изменения в этом файле. Это происходит только при обновлении файла Web.config. Таким образом, изменения в пользовательском файле конфигурации не проявляются в приложении сразу же. Нужно вручную остановить и перезапустить Web-приложение. Это еще одна причина, по которой следует использовать файл Web.config для задания параметров, применяемых в производственной среде, а файл User.config - только для параметров, применяемых при разработке и тестировании.

Обновление ссылок на Web-сервисы

Чтобы обновить существующую ссылку на Web-сервис, в Visual Studio .NET в окне Solution Explorer щелкните файл правой кнопкой мыши и выберите Update. При следующей сборке проекта будет загружен WSDL-документ с новой информацией о сервисе и сгенерирован новый прокси-класс Web-сервиса.

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

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

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

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

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

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

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

1. Добавьте атрибут file="user.config" в элемент appSettings главного файла конфигурации вашего приложения и укажите строку подключения по умолчанию в главном файле конфигурации. Она применяется, если пользователь не переопределяет ее в своем файле конфигурации.

   <configuration>
    <appSettings file="user.config">
     <add key="DBConnStr"
        value="server=PRODDB;Integrated Security=SSPI;database=Accounts"/>
    </appSettings>
   </configuration>
   

2. Чтобы переопределить параметры, содержащиеся в главном файле конфигурации приложения, создайте файл User.config (в той папке, где хранится файл конфигурации приложения) и добавьте в него аналогичную запись appSettings. Заметьте, что следующая строка подключения заставляет ссылаться на локальную базу данных.

   <appSettings>
     <add key="DBConnStr"
        value="server=(local);Integrated Security=SSPI;database=Accounts"/>
    </appSettings>
   

3. В своем проекте, чтобы получить строку подключения из пользовательского файла конфигурации (если такой файл есть) или из файла конфигурации приложения (если пользовательского файла нет), напишите код следующего вида. Он обращается к статическому свойству AppSettings класса System.Configuration.ConfigurationSetting.

   using System.Configuration;
   private string GetDBaseConnectionString()
   {
     return ConfigurationSettings.AppSettings["DBConnStr"];
   }
   

Разработка баз данных

Существует два основных подхода к разработке в групповой среде баз данных:

• с использованием централизованного сервера (или серверов) базы данных;
• с применением централизованного сервера (или серверов) базы данных и локальных баз данных на компьютерах разработчиков.

Централизованные серверы баз данных

Централизованный сервер (или серверы) баз данных в среде групповой разработки хранит зеркальную копию производственной схемы или, если схема еще не используется в производственной среде, самую последнюю версию схемы. При использовании серверов баз данных в среде групповой разработки руководствуйтесь следующими принципами.

• Не предоставляйте разработчикам административные права доступа к серверу базы данных и не разрешайте отдельным разработчикам изменять схему. Тщательно следите за средой, в которой работает группа, так как изменения, вносимые одним разработчиком, могут повлиять на работу других.
• Выдайте разработчикам специфические разрешения; например, разрешите им записывать в базу данных хранимые процедуры, функции и, возможно, представления (views).
• Управляйте изменениями в схеме и других объектах, например в хранимых процедурах, с помощью сценариев с контролируемыми исходными текстами.
• Используйте сценарии, чтобы упростить создание баз данных.
• Создайте отдельные экземпляры базы данных для разных направлений разработки, так как параметры конфигурации могут быть разными для каждого из разрабатываемых проектов.

Локальные базы данных

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

Поэтому во многих случаях на каждый компьютер разработчика устанавливается Microsoft SQL Server^™ Developer Edition, что позволяет каждому разработчику создать на своем компьютере изолированную среду тестирования.

Для внесения изменений используйте сценарии базы данных

Для внесения любых изменений в базу данных, хранящуюся на локальном или централизованном сервере, применяйте сценарии с контролируемыми исходными текстами. Пишите сценарии для любых изменений, даже если их можно было бы выполнить вручную в Enterprise Manager. Используйте сценарии базы данных (по возможности с ведением аудита и журнала ошибок), чтобы:

• обеспечить возможность создания базы данных с "нуля" (вместе с хранимыми процедурами и т. д.);
• обеспечить загрузку "свежего" набора тестовых данных;
• сохранить изменения в схеме базы данных и ее объектах.

Проекты баз данных в Visual Studio .NET

Сценарии баз данных должны храниться в виде исходных текстов и контролироваться VSS. Существует два способа управления сценариями.

• Разрабатывать сценарии вне IDE (Integrated Development Environment) Visual Studio .NET и вручную создавать структуру папок, которая может использоваться VSS. Так, можно создать в $/Projects/SystemName подпапку Database Objects - папку подпроекта, где хранятся относящиеся к базе данных код и объекты, а в ней в свою очередь создать подпапки, которые служат контейнерами для объектов разных видов, например: Tables and Views, Diagrams and Documentation и Stored Procedures and Functions.
• Использовать проекты баз данных Visual Studio .NET. Это просто проекты, которые состоят из файлов и позволяют хранить и выполнять сценарии базы данных, а также хранить другую информацию о базе данных, например документацию или сборочные файлы. В Visual Studio .NET интегрирован редактор кода Transact-SQL, визуальный инструмент Query Builder и поддерживается отладка сценариев T-SQL. Преимущество такого подхода - в тесной автоматической интеграции с VSS, а также в интеграции с другими типами проектов.

Ссылки на COM-объекты

Когда ваш код обращается к COM-объекту, для преобразования .NET-типов в COM-типы (и обратно) используется Interop-сборка. Если COM-объект вызывается из управляемого кода, то на самом деле происходит обращение к прокси-объекту в Interop-сборке. Прокси сначала выполняет необходимые преобразования типов, а затем вызывает COM-объект, делающий то, что от него требуется.

Всегда создавайте совместимые Interop-сборки

При групповой разработке, если вы и другой программист обращаетесь к одной и той же DLL COM-объекта из двух разных проектов, создаются две Interop-сборки - по одной для каждого проекта.

В большинстве случаев в этих двух сборках содержатся одни и те же типы, и вы можете безопасно передавать ссылку на COM-объект из одного проекта в другой (через Interop-сборку).

Чтобы типы, используемые создаваемыми Interop-сборками, гарантированно были одинаковыми, соблюдайте приведенные ниже правила. Отступление от этих правил приведет к генерации исключения "несоответствие типов" в период выполнения, когда ссылка из одного проекта будет передана в другой (даже если Interop-сборки были созданы для одной и той же DLL COM-объекта). Вот эти правила.

1. Все Interop-сборки следует генерировать по одной и той же версии библиотеки COM-типов.
2. Идентификация всех Interop-сборок должна быть одинаковой. Такая идентификация включает:
   1. имя файла без расширения;
   2. открытый ключ (может быть пустым);
   3. версию;
   4. культуру (для кода - обычно нейтральная культура).

Перечисленные выше условия обычно выполняются, когда вы генерируете Interop-сборку в среде Visual Studio .NET, выбирая библиотеку COM-типов в диалоговом окне Add References. Единственное исключение связано с тем, что в Visual Studio .NET (в C#-проектах) можно присваивать Interop-сборкам строгие имена (используя свойство Wrapper Assembly Key File, доступное в окне свойств проекта). В этом случае может оказаться, что два разработчика создадут две разные Interop-сборки, несовместимые друг с другом.

Чтобы гарантировать в среде групповой разработки, что для любой версии библиотеки COM-типов существует только одна Interop-сборка, используйте один из двух подходов.

1. Всегда применяйте первичные Interop-сборки (Primary Interop Assemblies, PIA).
2. Если PIA недоступна, создайте Interop-сборку вручную (с помощью tlbimp.exe), а затем:
   1. при необходимости присвойте сборке строгое имя;
   2. напрямую включите сборку в проекты, которые должны на нее ссылаться.

Оба этих подхода описываются в следующем разделе.

По возможности используйте PIA

PIA (Primary Interop Assembly) - это Interop-сборка, официально подписанная разработчиком COM-объекта и предназначенная для использования во всех случаях. Если у вас нет PIA, запросите ее у разработчика COM-объекта.

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

Примечание PIA, поставляемые с .NET Framework, находятся в папке \Program Files\Microsoft.NET\Primary Interop Assemblies. Когда вы получаете новые PIA, не помещайте их в эту папку; если вы так поступите, придется обновлять такие папки на всех компьютерах разработчиков и на сервере сборок. Копируйте PIA прямо в папки проектов, которые должны на них ссылаться.

Если у вас нет Primary Interop Assembly, используете TLBIMP

Если у вас нет PIA, создайте единственную Interop-сборку с помощью утилиты Tlbimp.exe и при необходимости присвойте ей строгое имя. Как и в случае PIA (и других сборок внешних систем), включите сгенерированную вручную Interop-сборку в проекты, которые должны на нее ссылаться. В результате сборка копируется в локальную папку проекта, который будет ссылаться на нее как на файл.

Регистрируйте COM-классы на локальном компьютере

Добавление Interop-сборки в проект не означает автоматического копирования на локальный компьютер (и регистрации) связанной с ней COM DLL. Поэтому вы должны вручную регистрировать COM DLL на каждой рабочей станции. Это расплата за взаимодействие с неуправляемым миром COM.

Вызов обслуживаемых компонентов

Обслуживаемый компонент - управляемый .NET-класс, производный от класса ServicedComponent в пространстве имен System.EnterpriseServices. Такие классы могут размещаться в COM+-приложениях как в контейнерах и использовать COM+-сервисы.

Применяя обслуживаемые компоненты в групповой среде разработки, примите во внимание следующие рекомендации.

Используйте отложенное подписание

У обслуживаемых компонентов должны быть строгие имена (strong names). Чтобы присвоить строгое имя, вам понадобится пара из открытого и закрытого ключа, которую можно сгенерировать утилитой Sn.exe. Во многих компаниях закрытый ключ - тщательно оберегаемая секретная информация, к которой разработчики не имеют повседневного доступа. Поэтому приходится использовать отложенное (или частичное) подписание (delayed signing), для которого достаточно только открытого ключа.

Частичное подписание приводит к тому, что в PE-файле (portable executable) сборки создается поле подстановки для сигнатуры строгого имени. Настоящее подписание откладывается на более поздний срок и выполняется в период между тестированием системы и ее выпуском. Обычно окончательное подписание сборок возлагается на координатора сборки.

Используйте динамическую регистрацию

Для поддержки динамической регистрации добавьте в сборку соответствующие атрибуты (например ApplicationName, ApplicationID и ApplicationActivation). Тогда COM-типы, связанные с вашими обслуживаемыми компонентами, будут автоматически установлены в каталог COM+ на всех компьютерах сразу после создания обслуживаемого компонента.

Контролируйте CLSID, хранящиеся в каталоге COM+

Когда вы повторно генерируете сборку, по умолчанию ей присваивается новый номер версии, так как при создании проекта Visual Studio .NET присваивает атрибуту AssemblyVersion значение "1.0.*". В итоге всякий раз, когда сборка собирается заново, для обслуживаемых компонентов генерируются новые CLSID (Class Identifiers).

Примечание
В проектах на C# и Visual Basic .NET это делается немного по-разному. В проектах на C# версия сборки увеличивается каждый раз, когда вы собираете ее заново, а в проектах на Visual Basic .NET - только когда вы в первый раз заново собираете проект после загрузки в Visual Studio .NET. При последующих повторных сборках, выполняемых в том же экземпляре Visual Studio .NET, версия сборки не увеличивается.

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

Для контроля CLSID обслуживаемого компонента, хранящегося в каталоге COM+, и во избежание появления новых версий всякий раз, когда разработчик повторно собирает обслуживаемый компонент, используйте один из двух способов.

1. Явно задавайте CLSID через атрибут Guid:

   [Guid("2136360E-FEBC-475a-95B4-3DDDD586E52A")]
   public interface IFoo
   {
   }
    
   [TransactionAttribute(TransactionOption.Required),
   Guid("57F01F20-9C0C-4e63-9588-720D5D537E66")]
   public class Foo: ServicedComponent, IFoo
   {
   }
   

2. Для сборок обслуживаемых компонентов задавайте статические номера версий и не применяйте схему нумерации версий "1.0.*", действующую в Visual Studio .NET по умолчанию. Подробнее об управлении версиями сборок см. в разделе Управление версиями сборок в главе 5 "Процесс сборки".