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

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

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

94731 / 64177 / 26122
Регистрация: 12.04.2006
Сообщений: 116,782
Ответы с готовыми решениями:

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

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

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

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

249 / 162 / 68
Регистрация: 10.12.2017
Сообщений: 558

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

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

17413 / 12809 / 3355
Регистрация: 17.09.2011
Сообщений: 21,086

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

Что делаю не так?
Убедитесь, что в прикрепленном проекте нет ошибок компиляции.
Регистрация: 27.01.2014
Сообщений: 116
Чем вообще отличаются действия «добавить ссылку на dll» и «добавить ссылку на проект»?

17413 / 12809 / 3355
Регистрация: 17.09.2011
Сообщений: 21,086

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

Чем вообще отличаются действия «добавить ссылку на dll» и «добавить ссылку на проект»?

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

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

Быстрое добавление ссылок или «прощай Add Reference»

Недавно я допилил одну проблему, которая меня уже очень давно достает. Суть ее в том, что диалог Add Reference в Visual Studio не нужен, если вы берете сборку из одного из тех мест, где их ищет студия. Не нужен он потому, что студия вполне могла бы сама проиндексировать все пространства имен в этих сборках и при написании using Biztalk дать мне возможность добавить ссылку автоматически. Поскольку студия это делать не умеет, пришлось ей помочь.

Идея сама по себе простая, и состоит из 2 х частей, а именно:

• Нужно найти все важные сборки и проиндексировать все их пространства имен.
• При наведении курсора на using , нужно сделать поиск всех возможных сборок и показать меню.

Индексирование

База для пространств имен и путям к файлам сборок делается за секунды. Единственный трюк – это использование Cecil вместо извращений вроде Assembly.ReflectionOnlyLoad() , которые пытаются подгрузить зависимости и ещё невесть что. Быстренько находим все типы, записываем их простнанства имен в HashSet , и засовываем все это в базу. Как? Об этом сейчас и поговорим.

Во-первых, пути к файлам которые использует Add Reference находятся как минимум в 2 х местах – в реестре, и в папке PublicAssemblies. Чтобы найти те папки, которые указаны в реестре, я написал следующий код:

public static IEnumerable < string >GetAssemblyFolders()

string [] valueNames = new [] < string .Empty, "All Assemblies In" >;

string [] keyNames = new []

@»SOFTWARE\Microsoft\.NETFramework\AssemblyFolders» ,

@»SOFTWARE\Wow6432Node\Microsoft\.NETFramework\AssemblyFolders»

>;

var result = new HashSet< string >();

foreach ( var keyName in keyNames)

using ( var key = Registry.LocalMachine.OpenSubKey(keyName))

if (key != null )

foreach ( string subkeyName in key.GetSubKeyNames())

using ( var subkey = key.OpenSubKey(subkeyName))

if (subkey != null )

foreach ( string valueName in valueNames)

string value = (subkey.GetValue(valueName) as string ?? string .Empty).Trim();

if (! string .IsNullOrEmpty( value ))

result.Add( value );

>

>

>

>

>

>

return result;

>

Изначально у меня мало что работало, т.к. ключи на 32-битной и 64-битной системе разные. В очередной раз замечаю что с переходом на 64-битную систему начал писать более качественный код 🙂

Чтобы найти папку PublicAssemblies, нужно сначала найти где установлена Visual Studio:

public static string GetVS9InstallDirectory()

var keyNames = new string []

@»SOFTWARE\Wow6432Node\Microsoft\VisualStudio\9.0\Setup\VS» ,

@»SOFTWARE\Microsoft\VisualStudio\9.0\Setup\VS»

>;

foreach ( var keyName in keyNames)

using ( var key = Registry.LocalMachine.OpenSubKey(keyName))

if (key != null )

return key.GetValue( «ProductDir» ).ToString();

>

>

return null ;

>

Имея список папок, можно в каждой искать все DLL-файлы и индексировать их. Помимо тех папок что всегда фигурируют в диалоге Add Reference, можно добавлять свои папки, что бывает удобно.

using ( var dc = new StatsDataContext())

var dirs = new HashSet< string >();

dirs.Add( @»C:\Program Files (x86)\JetBrains\ReSharper\v4.5\Bin» );

foreach ( var dir in GetAssemblyFolders()) dirs.Add(dir);

dirs.Add(Path.Combine(GetVS9InstallDirectory(), @»Common7\IDE\PublicAssemblies» ));

foreach ( string dir in dirs.Where(Directory.Exists))

string [] files = Directory.GetFiles(dir, «*.dll» );

var entries = new HashSet();

foreach ( string file in files)

var ns = AddNamespacesFromFile(file);

foreach ( var n in ns)

entries.Add(n);

>

dc.Namespaces.InsertAllOnSubmit(entries);

>

dc.SubmitChanges();

>

Добавление происходит с помощью метода AddNamespacesFromFile() который, как я уже писал, использует Mono.Cecil.

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

Использование

Не имея лучших вариантов, я реализовал добавление ссылок как context action для ReSharper. Идея простая – пользователь наводит курсор на слово Biztalk в строке using Biztalk; и видит магическое меню, при выборе элементов которого автоматически добавляется ссылка в проект.

Сам СА наследует от полезного класса CSharpContextActionBase , внутри которого кроме проверки а «применимость» ничего умного не происходит. Поиск по базе ведется с помощью простой выборки в стиле SELECT * from Namespaces where NamespaceName LIKE ‘%BizTalk%’ . Для базы в которой у вас будет пара тысяч элементов (ну, может 10 тысяч, если постараетесь), такой подход адекватен.

protected override bool IsAvailableInternal()

items = EmptyArray.Instance;

var element = GetSelectedElement( false );

if (element == null )

return false ;

var parent = element.ToTreeNode().Parent;

if (parent == null || parent.GetType().Name != «ReferenceName» || parent.Parent == null

|| string .IsNullOrEmpty(parent.Parent.GetText()))

return false ;

string s = parent.Parent.GetText();

if ( string .IsNullOrEmpty(s))

return false ;

var bulbItems = new HashSet();

using ( var conn = new SqlConnection(

«Data Source=(local);Initial Catalog=Stats;Integrated Security=True» ))

conn.Open();

var cmd = new SqlCommand(

«select * from Namespaces where NamespaceName like ‘%» + s + «%'» , conn);

using ( var r = cmd.ExecuteReader())

int count = 0;

while (r.Read())

bulbItems.Add( new RefBulbItem(

provider,

r.GetString(2).Trim(),

r.GetString(3).Trim(),

r.GetString(4).Trim()));

count++;

>

if (count > 0)

items = System.Linq.Enumerable.ToArray(

System.Linq.Enumerable.ThenBy(

System.Linq.Enumerable.OrderBy(

bulbItems,

i => i.AssemblyName),

i => i.AssemblyVersion));

return true ;

>

>

>

return false ;

>

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

protected override void ExecuteBeforeTransaction(ISolution solution,

JetBrains.TextControl.ITextControl textControl, IProgressIndicator progress)

var project = provider.Project;

if (project == null ) return ;

var fileSystemPath = FileSystemPath.TryParse(path);

if (fileSystemPath == null ) return ;

var assemblyFile = provider.Solution.AddAssembly(fileSystemPath);

if (assemblyFile == null ) return ;

var cookie = project.GetSolution().EnsureProjectWritable(project, out project, SimpleTaskExecutor.Instance);

QuickFixUtil.ExecuteUnderModification(textControl,

() => project.AddModuleReference(assemblyFile.Assembly),

cookie);

>

Код выше удалось написать только с помощью члена команды JetBrains (planerist – спасибо!), т.к. у меня у самого не хватило усидчивости чтобы найти правильный способ.

Заключение

Не знаю сколько я сэкономил времени путем реализации этого функционала, но головной боли в стиле «сидим ждем Add Reference» точно стало меньше. И компоновать проекты с моим любимым набором сборок (DI, Mocks, validation, utilities, etc.) стало намного проще. ■

Visual Studio — добавить ссылку на проект

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

Отслеживать

задан 20 июн 2018 в 14:46

293 4 4 серебряных знака 17 17 бронзовых знаков

возможно добавленный проект у вас не билдится, возможно у него есть свои зависимости, которые вы не добавили к вашему солюшену. После добавления проекта в солюшн, пробовали этот проект собрать отдельно от солюшена? (правый клик на проекте => Build)

20 июн 2018 в 22:02

да, проект сам билдится

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

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

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

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

В этой главе даны рекомендации по:

• разбиению решений и проектов Microsoft ® Visual Studio ® .NET;
• управлению локальной файловой системой и структурой каталогов Microsoft Visual SourceSafe ™ (VSS);
• применению соглашений об именовании к проектам, сборкам и пространствам имен.

Решения и проекты Visual Studio .NET

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

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

Проекты Visual Studio .NET

В Visual Studio .NET проекты служат контейнерами, где хранятся все конфигурационные параметры и параметры сборочного процесса, требуемые для создания .NET-сборки. У имен файлов проектов расширение либо .csproj, либо .vbproj в зависимости от языка проекта. Хотя существует много разных типов проектов [и соответствующих шаблонов быстрой разработки приложений (Rapid Application Development, RAD)], их можно разделить на две большие категории.

• Web-проекты. Такой проект создается с адресом, поддерживаемым Hypertext Transfer Protocol (HTTP), например http://localhost/MyWebProject. К Web-проектам относятся Web-приложения ASP.NET, предоставляющие контент Web-браузерам, а также Web-сервисы ASP.NET, применяемые в основном для интеграции данных через Интернет.
• Проекты, не связанные с Web (локальные). Эти проекты создаются в файловой системе (например C:\Projects\MySystem\MySolution\MyWinProject).

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

Решения Visual Studio .NET

Файлы решений (с расширением .sln) объединяют в группу связанные проекты и применяются в основном для управления процессом сборки. С их помощью можно управлять зависимостями и порядком, в котором собираются содержащиеся в них проекты.

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

Рис. 3.1 иллюстрирует связь между проектами и решениями и типы файлов, в которых VSS хранит параметры уровней решения и проекта.

Solution — Решение
Dependencies — Зависимости
Project — Проект
User Specific File (Not Version Controlled) — Файл, специфичный для пользователя (вне системы контроля версий)
AppName — Имя приложения
Non-User Specific File (Version Controlled) — Файл, не специфичный для пользователя (в системе контроля версий)

Рис. 3.1. Проекты и решения Visual Studio .NET

Решения и сборочные зависимости

Файл решения также содержит информацию о зависимостях проекта, используемую процессом сборки. Например, на предыдущей схеме такая информация указывает, что проект A зависит от проекта B, а тот в свою очередь зависит от проекта C. Когда ссылки на проекты используется в одном решении, Visual Studio .NET гарантирует корректный порядок сборки.

Внимание Существует два основных типа ссылок: на проекты и файловые. И те, и другие создаются в диалоговом окне Add References в Visual Studio .NET. Поскольку ссылки на проекты также определяют зависимости от порядка сборки, по возможности старайтесь применять именно их. Дополнительные сведения см. в разделе Ссылки на сборки главы 4 «Управление зависимостями».

Файлы, включаемые в систему контроля исходного кода

Далее приведены основные типы файлов, автоматически добавляемые к VSS при добавлении решения к системе контроля исходного кода с помощью Visual Studio .NET IDE.

• Файлы решений (*.sln). К основным элементам в этих файлах относятся список проектов, информация о зависимостях, параметры процесса сборки и настройки системы контроля исходного кода.
• Файлы проектов (*.csproj или *.vbproj). К основным элементам в этих файлах относятся параметры компиляции, сборки, на которые есть ссылки (по имени и пути), а также описание файла (file inventory).
• Конфигурационные файлы приложения. Основаны на XML (Extensible Markup Language) и применяются для управления свойствами проекта в период выполнения.
• Примечание Конфигурационный файл с контролем исходного кода для Web-приложений называется Web.config, а для приложений остальных типов — app.config и хранится в каталоге проекта. В период выполнения система сборки в Visual Studio .NET копирует App.config в папку Bin и переименовывает этот файл в Yourappname.exe.config.
• Конфигурационный файл для приложений, отличных от Web, не добавляется к новому проекту автоматически. Если вам нужен такой файл, добавьте его вручную. Убедитесь, что он называется App.config и находится в каталоге проекта.
• Файлы исходного кода (*.cs, *.vb, *.aspx, *.asax, *.resx, *.vsdisco, *.css, и т. д.). Все файлы исходного кода проекта включаются в систему контроля кода.
• Файлы, не включаемые в систему контроля исходного кода
• Следующие файлы не включаются в систему контроля исходного кода, так как они специфичны для каждого разработчика.
• Файлы пользовательских параметров решения (*.suo). Содержат персональные настройки IDE, заданные индивидуальным разработчиком.
• Файлы пользовательских параметров проекта (*.csproj.user или *.vbproj.user). Содержат специфические параметры проекта для разработчика, а также дополнительный (необязательный) путь поиска сборок, на которые есть ссылки в проекте. В разделе Ссылки на сборки главы 4 «Управление зависимостями» объясняется, как управлять ссылками на сборки в среде групповой разработки.
• Файлы WebInfo (*.csproj.webinfo или *.vbproj.webinfo). В этих файлах содержатся сведения о виртуальном корне приложения. Они не добавляются к системе контроля, чтобы разработчики могли указывать различные виртуальные корни для своих индивидуальных рабочих копий проекта. Хотя такая возможность есть, при разработке Web-приложений рекомендуется использовать один и тот же (локальный) виртуальный корень. Рекомендуемая структура для Web- и других приложений обсуждается в разделе Используйте постоянную структуру каталогов для решений и проектов.
• Результаты компиляции, в том числе динамически подключаемые библиотеки (DLL) сборок, DLL Interop-сборок и исполняемые файлы. Однако сборки внешних систем, не создаваемые в процессе компиляции вашей системы (например элементы управления и библиотеки от сторонних поставщиков), рекомендуется добавлять к VSS в рамках проекта, который ссылается на них. Дополнительные сведения см. в разделе Включение сборок внешних систем в проекты главы 4 «Управление зависимостями».

Всегда используйте Visual Studio .NET для операций, связанных с управлением исходным кодом

Все операции создания и управления проектом в VSS следует выполнять с помощью интегрируемых VSS-меню в Visual Studio .NET — не применяйте для этого VSS Explorer. Функциональность Visual Studio .NET гарантирует, что:

• к системе контроля будут добавлены только требуемые файлы;
• файлы проектов и решений Visual Studio .NET будут обновляться корректно. Например, функциональность VSS в Visual Studio .NET включает в файлы решений (.sln) следующие данные (в числе прочих):
• количество проектов в решении, поставленных на учет в системе контроля (счетчик включает и само решение);
• VSS-сервер для каждого проекта;
• местоположение сервера для каждого проекта;
• имя системы контроля для каждого проекта;
• местоположение каждого проекта относительно размещения файла решений.

Прочие файлы, в том числе пользовательский файл решения (.suo) и файл проекта (.csproj или .vbproj), тоже обновляются.

Внимание Всегда работайте с VSS через интерфейс Visual Studio .NET, а не через VSS Explorer. Тесная интеграция продуктов гарантирует корректное управление файлами в среде групповой разработки.

Разбиение решений и проектов на отдельные части

Способ разбиения решений и проектов существенно влияет на процессы разработки и сборки в среде групповой разработки.

Существует три основных модели разбиения решений и проектов. Их список дан в порядке предпочтительности:

1. Единое решение.
2. Единое решение, разбитое на части.
3. Несколько решений.

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

По возможности применяйте модель на основе единственного решения

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

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

• Если вам потребуется ссылка на другую сборку, создаваемую в отдельном проекте, вы можете воспользоваться ссылкой на проект. Такие ссылки предпочтительнее для создания ссылок на другие сборки, и они гарантированно работают на компьютерах всех разработчиков в среде групповой разработки. Преимущества ссылок на проекты и информация о том, в каких случаях следует использовать файловые ссылки, см. в разделе Ссылки на сборки главы 4 «Управление зависимостями».
• Нет проблем с контролем версий сборок, так как Visual Studio .NET сам распознает, когда необходимо перекомпилировать клиент сборки, на которую есть ссылка.
• Ссылки на проекты чувствительны к изменениям в конфигурации проекта, на который они указывают. То есть вы можете автоматически переключаться между режимами сборки Debug и Release без переустановки ссылок.
• Значительно упрощается процесс сборки системы и сборочный сценарий.

Недостатки

• масштабирование этой модели ограничено. Даже если вам понадобится всего один проект из решения, придется получать исходный код всех проектов этого решения;
• даже незначительные изменения в единственном файле исходного кода в одном проекте могут вызвать повторную сборку (rebuild) многих проектов в решении из-за зависимостей между проектами. Если в проекте, на который вы ссылаетесь, изменяется интерфейс сборки (assembly), вам потребуется перекомпилировать клиентский проект. А компиляция зависимых проектов может быть весьма длительной, особенно если в решении их много.

Для больших систем используйте модель, в которой решение разбивается на части

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

Это позволит вам и вашим коллегам работать над раздельными подсистемами меньшего размера в пределах внутренней системы.

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

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

File Reference — Файловая ссылка
Project Reference — Ссылка на проект
Solution 1 — Решение 1
Project — Проект
Outer System Boundary — Внешняя граница системы
Inner System Boundary — Внутренняя граница системы
External Assemblies Third Party Components — Внешние сборки и компоненты оот сторонних поставщиков
Master Solution — Главное решение

Рис. 3.3. Модель решения, разбитого на части

• все проекты содержатся в главном файле решения. Он используется сборочным процессом для сборки всей системы. Если вы работаете с файлом проекта верхнего уровня, вы работаете и с главным решением;
• между индивидуальными проектами существуют ссылки на проекты;
• для некоторых файлов проектов вводятся отдельные файлы решения. При желании можно создать файл решения для каждого проекта в системе. Каждый файл решения содержит файл основного проекта и все нижестоящие проекты, от которых он зависит, а также проекты, от которых зависят только что упомянутые нижестоящие проекты, — и так до конца по всей цепочке зависимостей;
• отдельные файлы решения позволяют работать с подсистемами меньшего размера, по-прежнему используя основные преимущества ссылок на проекты. В каждом файле подрешения между составляющими его проектами создаются ссылки на проекты.
  Примечание Не разделяйте два ссылающихся друг на друга проекта между решениями, так как в этом случае вам потребуется файловая ссылка, чего по возможности следует избегать. Подробнее на эту тему см. раздел Ссылки на сборки в главе 4 «Управление зависимостями».

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

• Вы можете работать с подсистемами меньшего размера. Исходный код и файлы проектов всей системы на каждой рабочей станции не нужны. В результате содержимое окна Solution Explorer в Visual Studio .NET останется ясным, и вам будет легче работать с этим средством.
• В каждом решении можно использовать ссылки на проекты.
• Главное решение позволяет легко перекомпилировать всю систему. Файл главного решения используется в сборочном процессе на сервере сборки.

Недостатки

• При добавлении нового проекта его, возможно, придется добавить к нескольким файлам решения и обновить в них ссылки на проекты; например, к главному файлу решения и к одному или нескольким другим файлам.
• Способ разбиения системы ограничен и определяется зависимостями. В итоге, если вы работаете с проектом верхнего уровня, например с Web-приложением ASP.NET на презентационном уровне, вам придется копировать все зависимые проекты на рабочую станцию. Вероятно, в их число войдут проекты бизнес-уровня и уровня данных. С другой стороны, если вы разрабатываете библиотеку классов или компонент доступа к данным с небольшим числом внутренних зависимостей (или вообще без них), вам потребуются только соответствующие проекты.

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

• нет главного файла решения;
• между проектами в разных решениях используются файловые ссылки (хотя ссылки на проекты по-прежнему применяются в рамках проектов одного решения);
• сценарий сборки системы, выполняемый на сервере сборки, последовательно компилирует каждое решение на основе известных отношений зависимости (dependency relationships). Сценарий сборки помещает результаты в фиксированное место на сервере.

Модель на основе несокльких решений показана на рис. 3.4.

File Reference — Файловая ссылка
Project Reference — Ссылка на проект
Solution — Решение
Project — Проект
Outer System Boundary — Внешняя граница системы
Inner System Boundary — Внутренняя граница системы
External Assemblies Third Party Components — Внешние сборки и компоненты от сторонних поставщиков

Рис. 3.4. Модель на основе нескольких решений

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

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

Недостатки

• Вам придется использовать файловые ссылки, когда возникнет необходимость в ссылке на сборку, создаваемую в проекте в другом решении. В отличие от ссылок на проекты файловые ссылки не создают автоматически сборочные зависимости. То есть вы должны решать проблему с порядком сборки решений на основе сценария сборки системы. Это, конечно, возможно, но усложняет сборочный процесс.
• Вам придется ссылаться на конкретную конфигурацию сборки DLL — например на Debug- или Release-версию. Ссылки на проекты автоматически разрешают подобные проблемы и ссылаются на конфигурацию, активную в данный момент в Visual Studio .NET.
• Работая с одним решением, вы можете получить последнюю версию кода (возможно, в других проектах), разработанного другими членами группы, для тестирования на локальную интеграцию. Вы можете быть уверенны, что ничего не случится до того, как вы поставите свой код на контроль в VSS, подготовив его к следующей сборке системы. Сделать то же самое в системе с несколькими решениями гораздо труднее, так как вы можете тестировать свое решение совместно с другими только по результатам предыдущей сборки системы.
  Вам будет несложно работать с единственным решением, содержащим 10, 20 или даже 30 проектов. Точное число проектов, уместных в конкретном решении, трудно порекомендовать, так как оно зависит от спецификаций сервера сборки и рабочих станций, а также от размера и количества исходных файлов в индивидуальных проектах.

Рекомендации по группировванию проектов в решения

• Начните с идентификации сборок (или компонентов), входящих в вашу систему; это позволит определить, какие проекты нужны для построения вашей системы. Не забудьте, что каждая сборка создается в отдельном проекте Visual Studio .NET.
• Ориентируйтесь на модель на основе одного решения. Если вы хотите разбить проекты и обеспечить более высокий уровень изоляции и контроля, то можете воспользоваться моделью решения, разбитого на части. Продумайте, с какими группами проектов вы хотите работать изолированно, например с набором бизнес-компонентов промежуточного уровня, и создайте соответствующие отдельные решения.
  Если вы хотите распределить проекты по нескольким решениям, но не можете добиться этого на основе модели решения, разбитого на части, проверьте все зависимости между решениями и природу интерфейсов, разделяющих две зависимые сборки. При организации проектов в виде отдельных решений следует:
• определить внешние интерфейсы, разделяющие составные части системы. Попробуйте выявить те из них, которые в наименьшей степени будут требовать изменений. Если интерфейс, реализуемый одним из проектов, часто меняется, все зависимые проекты в идеале следует включить в одно решение;
• если для соединения некоторых компонентов системы используются Web-сервисы, разделительной линией можно считать интерфейс Web-сервиса. Например, проекты на клиентской стороне интерфейса Web-сервиса и проекты на серверной стороне — хорошие кандидаты для отдельных решений.

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

Работать в среде групповой разработки становится гораздо легче, если для хранения решений и проектов Visual Studio .NET используется общая структура. Чтобы добиться симметричности (и в итоге упрощения), настройте в VSS структуру папок, соответствующую структуре вашей локальной файловой системы.

Определите общую корневую папку

Определите общую корневую папку, например C:\Projects в файловой системе и $/Projects в VSS. Она будет служить контейнером для всех разрабатываемых систем.

В общей корневой папке создайте корневые папки для всех систем, например C:\Projects\MyCompanysInsuranceApp и $/Projects/MyCompanysInsuranceApp соответственно.

Применяйте иерархическую структуру папок для решений и проектов

• создайте подпапку в корневой папке системы для своего решения Visual Studio .NET;
• в ней для каждого проекта в решении создайте дополнительные дочерние подпапки;
• используйте эту структуру для Web- и любых других приложений;
• не добавляйте папку Bin или ее содержимое к VSS.

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

Рекомендуемая структура показана на рис. 3.5.

VS .NET Folder Structure — Структура папок VS .NET
VSS Folder Structure — Структура папок VSS

Рис. 3.5. Структуры папок в Visual Studio .NET и VSS

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

Как создать новый Web-проект ASP.NET

По умолчанию при создании нового Web-приложения ASP.NET файл проекта помещается в выбранный виртуальный корень — подпапку Web-сайта по умолчанию (обычно в \inetpub\wwwroot), а связанный с ним файл решений записывается в подпапку \My Documents\Visual Studio Projects. Такое размещение по умолчанию неидеально в среде групповой разработки, так как нарушает симметричность структур проектов в VSS и локальных файлов.

А теперь детально рассмотрим создание нового Web-приложения ASP.NET в соответствии с рекомендованной структурой папок в решении и проектах. Пусть решение называется MyWebAppSolution, а проект — MyWebApp.

Включайте в имя решения слово Solution или Soln — так проще различать имена решения и проекта.

Рекомендуемая структура приведена на рис. 3.6. Заметьте, что папка проекта и виртуальный корень Microsoft Internet Information Server (IIS) совпадают.

Local File System — Локальная файловая система
VSS Project Structure — Структура проекта VSS
Project folder AND IIS Virtual Root — Папка проекта и виртуальный корень IIS

Рис. 3.6. Рекомендуемая структура Web-приложения

Чтобы создать новое Web-приложение с такой структурой

1. Откройте Visual Studio .NET, в меню File выберите New и щелкните BlankSolution.
2. Введите MyWebAppSolution в качестве имени решения и укажите его расположение — \Projects\MySystem.
3. Щелкните OK. Visual Studio .NET создаст папку MyWebAppSolution в указанном корневом каталоге.
4. В Windows Explorer создайте новую подпапку MyWebApp в папке \Projects\MySystem\MyWebAppSolution.
5. С помощью Windows Explorer или Internet Services Manager задайте MyWebApp в качестве виртуального корня IIS.
   ПримечаниеVisual? Studio .NET требует, чтобы имя виртуального корня совпадало с именем папки проекта.
6. Вернитесь в Visual Studio .NET и в меню File выберите AddProject, а затем щелкните NewProject.
7. Добавьте проект ASP.NET Web Application.
8. В поле Location введите http://localhost/MyWebApp и щелкните OK. В указанном виртуальном корне будут созданы исходные файлы Web-проекта.

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

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

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

Дополнительные сведения

Более подробную информацию о создании подпроектов Web-приложений см. статью Q307467 «HOWTO: Compose a Visual Studio 7 .NET ASP.NET application out of multiple project to facilitate team development,» в Microsoft Knowledge Base.

Работа с файлами отделенного кода ASP.NET

Следует помнить, что при снятии с контроля файла Web-формы (aspx) или файла отделенного кода (code-behind file) (aspx.cs или aspx.vb) Visual Studio .NET автоматически снимает с контроля оба файла. Так сделано потому, что изменения в пользовательском интерфейсе обычно требуют модификации файла отделенного кода.

Например, если вы добавите новый элемент управления на Web-форму, Visual Studio .NET автоматически создаст для него переменную-член в файле отделенного кода.

Как создать новый проект, отличный от Web-приложения

Далее рассказывается, как создать проект, отличный от Web-приложения, скажем, консольную или Windows-программу, библиотеку классов или сервис. Предполагается, что решение называется MyWinAppSolution, а проект — MyWinApp. Рекомендуемая структура приведена на рис. 3.7.

Local File System — Локальная файловая система
VSS Project Structure — Структура проекта VSS

Рис. 3.7. Рекомендуемая структура проекта для приложений, не связанных с Web

Чтобы создать новое приложение, отличное от Web, с такой структурой

1. Откройте Visual Studio .NET и в меню File выберите New, а затем щелкните Project.
2. Выберите подходящий тип проекта и шаблон.
3. Введите имя проекта в поле Name (в этом примере — MyWinApp).
4. В поле Location введите \Projects\MySystem.
5. Щелкните кнопку More.
6. Установите флажок Create directory for solution. В результате файл проекта будет создан в подпапке проекта в папке решения.
7. Введите MyWinAppSolution в поле New Solution Name.
8. Щелкните OK, чтобы завершить процесс создания проекта и решения.

О добавлении нового проекта и решения к Visual SourceSafe см. раздел Как зарегистрировать в VSS новое решение главы 6 «Работа с Visual SourceSafe».

Тщательно обдумайте соглашения об именовании

Тщательно и заранее обдумайте, как вы будете именовать проекты, сборки, папки и пространства имен. Хотя эти элементы можно переименовать на более поздних этапах цикла разработки, старайтесь этого избегать. О том, как переименовать проект, см. раздел Переименование проекта главы 6 «Работа с Visual SourceSafe».

Также стремитесь к непротиворечивости имен, поскольку это существенно упрощает организацию проекта.

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

Имя выходной сборки должно всегда совпадать с именем проекта, в котором она создается. Например, сборка MyCompany.Utilities.Data.dll должна создаваться в проекте MyCompany.Utilities.Data.

При изменении имени выходной сборки измените имя проекта и наоборот.

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

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

Так, в сборке MyCompany.Utilities.Data.dll корневое пространство имен должно называться MyCompany.Utilities.Data.

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

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

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

Используйте общие имена для папок VSS и локальных папок

Как уже говорилось, синхронизируйте имена папок решений и проектов с эквивалентными именами папок в VSS.