Структурирование решений и проектов

Структурирование решений и проектов

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

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

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

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

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

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

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

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

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

Файловые ссылки (file references) следует использовать только для сборок внешних систем (в том числе, для сборок .NET Framework и от сторонних поставщиков), не компилируемых вместе с вашей системой.

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

Рис. 3.2. Модель на основе единственного решения

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

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

Модель на основе единственного решения обеспечивает следующие преимущества.

Если вам потребуется ссылка на другую сборку, создаваемую в отдельном проекте, вы можете воспользоваться ссылкой на проект. Такие ссылки предпочтительнее для создания ссылок на другие сборки, и они гарантированно работают на компьютерах всех разработчиков в среде групповой разработки. Преимущества ссылок на проекты и информация о том, в каких случаях следует использовать файловые ссылки, см. в разделе Ссылки на сборки главы 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 используется общая структура. Чтобы добиться симметричности (и в итоге упрощения), настройте в 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-приложение с такой структурой

Откройте Visual Studio .NET, в меню File выберите New и щелкните Blank Solution.
Введите MyWebAppSolution в качестве имени решения и укажите его расположение - \Projects\MySystem.
Щелкните OK. Visual Studio .NET создаст папку MyWebAppSolution в указанном корневом каталоге.
В Windows Explorer создайте новую подпапку MyWebApp в папке \Projects\MySystem\MyWebAppSolution.
С помощью Windows Explorer или Internet Services Manager задайте MyWebApp в качестве виртуального корня IIS.
ПримечаниеVisual? Studio .NET требует, чтобы имя виртуального корня совпадало с именем папки проекта.
Вернитесь в Visual Studio .NET и в меню File выберите Add Project, а затем щелкните New Project.
Добавьте проект ASP.NET Web Application.
В поле 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, с такой структурой

Откройте Visual Studio .NET и в меню File выберите New, а затем щелкните Project.
Выберите подходящий тип проекта и шаблон.
Введите имя проекта в поле Name (в этом примере - MyWinApp).
В поле Location введите \Projects\MySystem.
Щелкните кнопку More.
Установите флажок Create directory for solution. В результате файл проекта будет создан в подпапке проекта в папке решения.
Введите MyWinAppSolution в поле New Solution Name.
Щелкните 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.

Это глава 3 из руководства Team Development with Visual Studio .NET and Visual SourceSafe. Следующую главу читайте по ссылке Управление зависимостями.