Рішення та проекти 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)], їх можна
розділити на дві великі категорії.

До найбільш поширених типів локальних проектів відносяться
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.

Завжди використовуйте Visual Studio. NET для операцій, пов'язаних з
управлінням вихідним кодом

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

Інші файли, в тому числі для користувача файл рішення (. Suo) і файл
проекту (. csproj або. vbproj), теж оновлюються.

Увага Завжди працюйте з VSS через інтерфейс Visual Studio
. NET, а не через VSS Explorer. Тісна інтеграція продуктів гарантує
коректне управління файлами в середовищі групової розробки.

Розбиття рішень та проектів на окремі частини

Спосіб розбиття рішень і проектів істотно впливає на процеси
розробки і збірки в середовищі групової розробки.

Існує три основні моделі розбиття рішень і проектів. Їх
список дано в порядку переваги:

  1. Єдине рішення.
  2. Єдине рішення, розбите на частини.
  3. Кілька рішень.

Увага Якщо у вас немає вагомих причин на те, щоб
задіяти модель на основі декількох рішень, уникайте її і
приймайте або модель на основі єдиного рішення, або (для
великих систем) модель на основі рішення, розбитого на частини. З ними
простіше працювати, до того ж, у них є ряд важливих переваг у
порівняно з моделлю на основі декількох рішень, про що і розповідається
в наступних розділах.

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

У моделі на основі єдиного рішення ви створюєте одне рішення
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.
    • Орієнтуйтеся на модель на основі одного рішення. Якщо ви
      хочете розбити проекти і забезпечити більш високий рівень ізоляції і
      контролю, то можете скористатися моделлю вирішення, розбитого на
      частини. Продумайте, з якими групами проектів ви хочете працювати
      ізольовано, наприклад з набором бізнес-компонентів проміжного
      рівня, і створіть відповідні окремі рішення.
      Якщо ви хочете розподілити проекти з кількома рішеннями, але не
      можете домогтися цього на основі моделі рішення, розбитого на частини,
      перевірте всі залежності між рішеннями і природу інтерфейсів,
      поділяють два залежні збірки. При організації проектів у вигляді
      окремих рішень слід:
    • визначити зовнішні інтерфейси, що розділяють складові частини
      системи. Спробуйте виявити ті з них, які найменшою мірою
      будуть вимагати змін. Якщо інтерфейс, реалізований одним з
      проектів, часто змінюється, всі залежні проекти в ідеалі варто
      включити в одне рішення;
    • якщо для з'єднання деяких компонентів системи використовуються
      Web-сервіси, розділовою лінією можна вважати інтерфейс
      Web-сервісу. Наприклад, проекти на клієнтській стороні інтерфейсу
      Web-сервісу і проекти на серверній стороні – хороші кандидати для
      окремих рішень.

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

    Працювати в середовищі групової розробки стає набагато легше, якщо
    для зберігання рішень і проектів Visual Studio. NET використовується загальна
    структура. Щоб домогтися симетричності (і в підсумку спрощення),
    налаштуйте у VSS структуру папок, відповідну структурі вашої
    локальної файлової системи.

    Визначте загальну кореневу папку

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

    У загальній кореневій папці створіть кореневі папки для всіх систем,
    наприклад, C: ProjectsMyCompanysInsuranceApp і
    $ / 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-сайту за
    замовчуванням (звичайно в inetpubwwwroot), а пов'язаний з ним файл рішень
    записується в підпапку My DocumentsVisual 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
      і клацніть Blank Solution.
    2. Введіть MyWebAppSolution в якості імені рішення і
      вкажіть його розташування – ProjectsMySystem.
    3. Клацніть OK. Visual Studio. NET створить папку
      MyWebAppSolution у вказаному кореневому каталозі.
    4. У Windows Explorer створіть нову підпапку MyWebApp в папці
      ProjectsMySystemMyWebAppSolution.
    5. За допомогою Windows Explorer або Internet Services Manager задайте
      MyWebApp в якості віртуального кореня IIS.
      ПриміткаVisual? Studio. NET вимагає, щоб ім'я віртуального
      кореня збігалося з ім'ям папки проекту.
    6. Поверніться в Visual Studio. NET і в меню File виберіть
      Add
      Project, А потім клацніть New Project.
    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 введіть ProjectsMySystem.
    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.

    Це глава 3 з керівництва Team Development with Visual Studio
    . NET and Visual SourceSafe. Наступну главу читайте за посиланням

    Управління залежностями.

  • Схожі статті:


    Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

    Коментарів поки що немає.

    Ваш отзыв

    Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

    *

    *