Как добавить ссылку на проект с visual studio

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

В references появляется этот проект. Проект не билдится, т.к. IDE не видит DLL для используемого в коде класса (видимо так). Если сделать AddReference на DLL – всё ок, билдится.
Что делаю не так? Нужно указать ссылку именно на проект, а не DLL.

Не могу добавить ссылку
Не могу добавить ссылку на офис, пишет такое. А саму ссылку Microsoft.Office.Core я не найду. Что.

Добавить защищенный паролем проект
Возможно ли добавить в солюшен защищенный паролем проект? чтобы исходные коды некоторых проектов.

Добавить существующий проект в TFS
После переустановки винды открываю проект, т.к рабочую область VS не находит он открывает как.

Не могу добавить новый item в проект
С какого-то времени не могу добавить новый item в проект. Всегда появляется сообщение: The.

На (папке) солюшена (решение) (Right click)-> Project dependencies. -> в выпадающем списке выбрать нужный проект, поставить галки.

На (папке) солюшена (решение) (Right click) -> Project Build Order. посмотреть все ли хорошо

Сообщение от olegall

Сообщение от olegall

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

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

How to Add References to Your Visual Studio Project

The steps below describe how to add references (.dll’s or .exe’s) to your Visual Studio project.

Note: This how-to does not cover how to use Service References or Web References.

1. Within your project in Visual Studio, you must first open the Reference Manage dialog box. This can be accomplished two ways:
   • From the toolbar, select Project — Add Reference
   • In the Solution Explorer pane, Right click the project then select Add — Reference .
2. Within the Reference Manager, you select the appropriate category. Categories include:
   • Framework — This includes all .Net libraries installed on the local machine
   • Projects — This includes all class library projects in your Visual Studio Solution
   • Com — This includes any Com components registered on the local machine.
   • Browse — this opens a file explorer dialog box and allows you to locate the appropriate dll or exe.
3. Using the Reference Manager, Choose the category and library within that category. In the example below, I have chosen the System.Web library in the Framework category.
4. Once an item is selected, click the OK button and the reference will be added to your project. You can view the references in your project by expanding the references category within your project.
5. You can also use the object explorer to browse the classes contained within the referenced library.

Как добавить ссылку на проект с visual studio

Управление ссылками в проекте

Перед написанием кода для внешних компонентов или подключенных служб необходимо включить в проект ссылки на них. По сути, ссылка — это запись в файле проекта, которая содержит сведения, необходимые Visual Studio для поиска компонента или службы.

Чтобы добавить ссылку, в обозревателе решений щелкните правой кнопкой мыши узел Ссылки или Зависимости и выберите команду Добавить ссылку. Вы также можете щелкнуть узел проекта правой кнопкой мыши и выбрать пункт Добавить > Ссылка. Дополнительные сведения см. в разделе Практическое руководство. Добавление и удаление ссылок.

Вы можете добавить ссылку на следующие типы компонентов и служб:

Библиотеки классов или сборки .NET

Приложения универсальной платформы Windows

другие сборки или библиотеки классов проектов в том же решении;

Ссылки на приложения UWP

Ссылки на проекты

Проекты универсальной платформы Windows (UWP) могут создавать ссылки на другие проекты UWP в решении либо на двоичные файлы или проекты, ориентированные на Windows 8.1, при условии, что эти проекты не используют интерфейсы API, которые являются устаревшими в Windows 10 и более поздних версиях. Более подробную информацию см. в разделе Перенос приложения из среды выполнения Windows 8 в UWP.

Если вы решили изменить целевую платформу проектов Windows 8.1 на Windows 10 или более поздней версии, ознакомьтесь со статьей Перенос, миграция и обновление проектов Visual Studio.

Справочник по пакетам SDK расширений

Приложения UWP на Visual Basic, C#, C++ и JavaScript могут ссылаться на пакеты SDK расширений, предназначенные для Windows 8.1, при условии, что эти пакеты SDK расширений не используют API, которые являются нерекомендуемыми в Windows 10 и более поздних версиях. Проверьте сайт поставщика пакета SDK расширений, чтобы выяснить, могут ли на него ссылаться приложения UWP.

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

Посмотреть имя проекта, который вызывает ошибку. Платформа, для которой предназначен этот проект, указывается в скобках рядом с именем проекта. Например, MyProjectName (Windows 8.1) означает, что проект MyProjectName предназначен для платформы Windows 8.1.

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

[!NOTE] Один из способов узнать, имеет ли пакет SDK расширений зависимости от других пакетов SDK расширений, — воспользоваться диспетчером ссылок. Перезапустите Visual Studio, создайте проект C# приложения UWP. Щелкните его правой кнопкой мыши и выберите пункт Добавить ссылку. Перейдите на вкладку Windows, а затем на вложенную вкладку Расширения. Выберите пакет SDK расширений. Посмотрите на правую панель в диспетчере ссылок. Если этот пакет имеет зависимости, они будут перечислены в этой панели.

[!IMPORTANT] Если проект предназначен исключительно для Windows 10 и установленный в предыдущем шаге пакет SDK расширений имеет зависимость от пакета среды выполнения Microsoft Visual C++, то совместимой с Windows 10 версией этого пакета является v14.0, которая устанавливается вместе с Visual Studio.

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

Перезапустите Visual Studio и откройте ваше приложение.

Щелкните правой кнопкой мыши узел Ссылки или Зависимости в проекте, который вызвал ошибку, и выберите команду Добавить ссылку.

Откройте вкладку Windows, а затем вложенную вкладку Расширения, после чего снимите флажки для старых пакетов SDK расширений и установите флажки для новых пакетов SDK расширений. Нажмите кнопку ОК.

Добавление ссылки во время разработки

При создании ссылки на сборку в проекте Visual Studio ищет сборку в следующих расположениях:

Каталог текущего проекта. (Можно найти эти сборки, используя вкладку Обзор .)

Другие каталоги проектов в одном решении. (Вы можете найти эти сборки на вкладке Проекты .)

• Все проекты содержат неявную ссылку на библиотеку mscorlib.
• Все проекты содержат неявную ссылку на System.Core , даже если System.Core была удалена из списка ссылок.
• Проекты Visual Basic содержат неявную ссылку на xref:Microsoft.VisualBasic.

Ссылки на общие компоненты во время выполнения

Во время выполнения компоненты должны быть в выходном пути проекта или в глобальном кэше сборок. Если проект содержит ссылку на объект, который не находится ни в одном из этих расположений, необходимо скопировать ссылку на выходной путь проекта во время сборки проекта. Свойство xref:Microsoft.VisualStudio.VCProjectEngine.VCProjectReference.CopyLocal%2A указывает, следует ли делать копию. Если значение True, ссылка копируется в каталог проекта во время сборки проекта. Если значение False, ссылка не копируется.

При развертывании приложения, которое содержит ссылку на пользовательский компонент, зарегистрированный в GAC, компонент не будет развернут в приложении независимо от параметра xref:Microsoft.VisualStudio.VCProjectEngine.VCProjectReference.CopyLocal%2A . В более ранних версиях Visual Studio можно было задать свойство xref:Microsoft.VisualStudio.VCProjectEngine.VCProjectReference.CopyLocal%2A ссылки, чтобы обеспечить развертывание сборки. Теперь необходимо вручную добавить сборку в папку \Bin. Далее весь пользовательский код будет тщательно проверен, что снизит вероятность публикации неизвестного пользовательского кода.

По умолчанию для свойства xref:Microsoft.VisualStudio.VCProjectEngine.VCProjectReference.CopyLocal%2A задается значение False , если сборка или компонент находится в глобальном кэше сборок или является компонентом платформы. В противном случае задается значение True. Ссылки проектов на проекты всегда имеют значение True.

Ссылка на проект или сборку, которые предназначены для другой версии .NET

Разработчики могут создавать приложения, которые ссылаются на проекты или сборки, предназначенные для другой версии платформы .NET. Например, вы можете создать приложение, предназначенное для .NET Framework 4.6 и ссылающееся на сборку, которая предназначена для .NET Framework 4.5. При создании проекта, предназначенного для более ранней версии .NET, задание в этом проекте ссылки на проект или сборку для более новой версии невозможно.

Ссылки проектов на проекты

Ссылки проектов на проекты — это ссылки на проекты, которые содержат сборки. Вы добавляете их на вкладке Проекты диалогового окна «Диспетчер ссылок». Visual Studio может найти сборку, если задан путь к проекту.

Если имеется проект, создающий сборку, необходимо сослаться на него и не использовать ссылку на файл (см. ниже). Преимущество ссылки проекта на проект состоит в том, что она создает зависимость между проектами в системе сборки. Зависимый проект будет собран, если он был изменен с момента последней сборки ссылающегося проекта. Ссылка на файл не создает зависимость сборки, поэтому можно собрать ссылающийся проект, не создавая зависимый, и ссылка может устареть. (То есть проект может ссылаться на ранее собранную версию проекта.) Это может привести к тому, что в каталоге bin потребуется несколько версий одной библиотеки DLL, что невозможно. При возникновении этого конфликта вы увидите сообщение «Предупреждение. Невозможно скопировать зависимость file из проекта project в каталог выполнения, поскольку она перезапишет ссылку file». Дополнительные сведения см. в статьях Диагностика неработающих ссылок и Практическое руководство. Создание и удаление зависимостей проекта.

[!NOTE] Ссылка на файл вместо ссылки проекта на проект создается, если целевая версия .NET Framework одного проекта — 4.5, а целевая версия другого проекта — 2, 3, 3.5 или 4.0.

Ссылки на общий проект

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

Ссылки на файлы

Ссылки на файлы — это прямые ссылки на сборки вне контекста проекта Visual Studio. Они создаются на вкладке Обзор диспетчера ссылок. Ссылку на файл следует использовать в случае, если имеется лишь сборка или компонент, но не проект, который создает ее в качестве выходных данных.

Как добавить ссылку на проект с visual studio

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

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

Примечание Сборки наподобие 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 диалогового окна AddReferences. В среде групповой разработки такие сборки не создают проблем, так как на всех компьютерах они находятся в общем для всех проектов месте.
2. Сборки внешних систем (outer system assemblies), подключаемые в диалоговом окне AddReferences с помощью кнопки Browse. К ним относятся компоненты сторонних поставщиков и сборки, созданные в вашей компании, но не входящие в состав текущей системы. О том, как управлять этим типом сборок, см. в разделе Включение сборок внешних систем в проекты.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сценарий сборки регулярно (обычно ежедневно) обновляет сборки, хранящиеся на сервере, до текущих версий. Как правило, сценарий сборки генерирует отладочные и финальные версии сборок. Разработчики используют отладочные 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. Раскройте папку CommonProperties и щелкните ReferencePath.
3. Для проектов на C#: щелкните значок NewLine и введите новый путь к ссылкам.
   — или —
   Для проектов на Visual Basic .NET: введите путь к ссылкам в поле Folder и щелкните Add Folder.
4. Щелкните OK, чтобы закрыть диалоговое окно Properties.

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

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

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

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

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

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

• Сборки внешних систем находятся под контролем вместе с файлами проектов. Когда появляется новая версия сборки, ее можно добавить в 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) в одном из следующих разделов реестра:
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 не "зашивается" в прокси: указать для свойства URLBehavior ссылки на 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 будет автоматически считывать параметры из пользовательского файла конфигурации. Если такого файла нет, берутся параметры из главного файла конфигурации приложения — ошибка периода выполнения не генерируется.

Обновление ссылок на 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 главного файла конфигурации вашего приложения и укажите строку подключения по умолчанию в главном файле конфигурации. Она применяется, если пользователь не переопределяет ее в своем файле конфигурации.
2. Чтобы переопределить параметры, содержащиеся в главном файле конфигурации приложения, создайте файл User.config (в той папке, где хранится файл конфигурации приложения) и добавьте в него аналогичную запись appSettings. Заметьте, что следующая строка подключения заставляет ссылаться на локальную базу данных.
3. В своем проекте, чтобы получить строку подключения из пользовательского файла конфигурации (если такой файл есть) или из файла конфигурации приложения (если пользовательского файла нет), напишите код следующего вида. Он обращается к статическому свойству AppSettings класса System.Configuration.ConfigurationSetting.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Разрабатывать сценарии вне IDE (Integrated Development Environment) Visual Studio .NET и вручную создавать структуру папок, которая может использоваться VSS. Так, можно создать в $/Projects/SystemName подпапку DatabaseObjects — папку подпроекта, где хранятся относящиеся к базе данных код и объекты, а в ней в свою очередь создать подпапки, которые служат контейнерами для объектов разных видов, например: Tables and Views, DiagramsandDocumentation и 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. Для чего нужен скайп
      2. Как зайти в рекавери на самсунг
      3. Как переименовать вай фай
      4. Чем отличается расширение doc от docx