Найкращі практики для великих рішень у Visual Studio (2008) [закрито]

У нас є рішення з приблизно 100+ проектами, більшість з яких - C #. Природно, що і відкриття, і будівництво займає багато часу, тому я шукаю найкращі практики для таких звірів. Поряд із питаннями, на які я сподіваюся отримати відповіді, є:

• як найкраще обробляти посилання між проектами
  • слід увімкнути чи вимкнути функцію "копіювати локально"?

• чи кожен проект повинен будувати у власній папці, або всі вони повинні будувати в одній папці виводу (всі вони є частиною однієї програми)

• Чи є папки рішень хорошим способом упорядкування матеріалів?

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

Можливо, вас зацікавлять ці дві статті MSBuild, які я написав.

MSBuild: Найкращі практики створення надійних збірок, частина 1

MSBuild: Найкращі практики створення надійних збірок, частина 2

Зокрема, у Частині 2 є розділ Створення великих дерев-джерел, на які Ви, можливо, захочете поглянути.

Щоб коротко відповісти на ваші запитання тут:

• CopyLocal? Напевно вимкніть це
• Побудувати в одну або кілька папок виводу? Збірка до однієї вихідної папки
• Папки з рішеннями? Це питання смаку.

Саєд Ібрагім Хашимі

Моя книга: Всередині Microsoft Build Engine: Використання MSBuild і Team Foundation Build

+1 за щадне використання папок з рішеннями для організації впорядкованих матеріалів.

+1 для побудови проекту до власної папки. Спочатку ми спробували загальну вихідну папку, і це може призвести до тонких і болючих пошуків застарілих посилань.

FWIW, ми використовуємо посилання на проекти для рішень, і хоча nuget, мабуть, сьогодні кращий вибір, виявив, що svn: externals добре працює як для сторонніх, так і для внутрішніх збірок (типу фреймворка). Просто увійдіть у звичку використовувати конкретний номер редакції замість HEAD при посиланні на svn: externals (винний за звинуваченням :)

Розвантажте проекти, якими ви не часто користуєтесь, і придбайте твердотільний диск. SSD не покращує час компіляції, але Visual Studio стає вдвічі швидшим для відкриття / закриття / побудови.

У нас є подібна проблема, оскільки ми маємо вирішити 109 окремих проектів. Щоб відповісти на оригінальні запитання, спираючись на наш досвід:

1. Як ви найкраще обробляєте посилання між проектами

Ми використовуємо опцію контекстного меню "додати посилання". Якщо вибрано "проект", то залежність додається до нашого єдиного, глобального файлу рішення за замовчуванням.

2. Чи слід увімкнути чи вимкнути функцію "копіювати локально"?

З нашого досвіду вимкнено. Додаткове копіювання просто збільшує час побудови.

3. Чи повинен кожен проект будувати свою власну папку, або всі вони повинні будувати одну і ту ж вихідну папку (всі вони є частиною однієї програми)

Весь наш результат розміщується в одній папці, що називається 'bin'. Ідея полягає в тому, що ця папка така ж, як і при розгортанні програмного забезпечення. Це допомагає запобігти проблемам, які виникають, коли налаштування розробника відрізняються від налаштувань розгортання.

4. Чи є папки рішень хорошим способом упорядкування матеріалів?

Ні, за нашим досвідом. Структура папок однієї людини - це кошмар іншої людини. Глибоко вкладені папки просто збільшують час, необхідний для пошуку чогось. Ми маємо абсолютно рівну структуру, але називаємо наші файли проектів, збірки та простори імен однаково.

Наш спосіб структурування проектів спирається на один файл рішення. Побудова цього займає багато часу, навіть якщо самі проекти не змінилися. Щоб допомогти в цьому, ми зазвичай створюємо інший файл рішення "поточного робочого набору". Будь-які проекти, над якими ми працюємо, додаються до цього. Час побудови значно покращений, хоча одна з проблем, яку ми бачили, полягає в тому, що Intellisense не працює для типів, визначених у проектах, яких немає в поточному наборі.

Частковий приклад макета нашого рішення:

\bin

OurStuff.SLN

OurStuff.App.Administrator
OurStuff.App.Common
OurStuff.App.Installer.Database
OurStuff.App.MediaPlayer
OurStuff.App.Operator
OurStuff.App.Service.Gateway
OurStuff.App.Service.CollectionStation
OurStuff.App.ServiceLocalLauncher
OurStuff.App.StackTester
OurStuff.Auditing
OurStuff.Data
OurStuff.Database
OurStuff.Database.Constants
OurStuff.Database.ObjectModel
OurStuff.Device
OurStuff.Device.Messaging
OurStuff.Diagnostics
...
[etc]

Ми працюємо над подібним великим проектом тут. Папки рішень виявилися хорошим способом організації речей, і ми, як правило, просто залишаємо локальний набір копій істинним. Кожен проект будується у свою папку, і тоді ми знаємо, що для кожного розгортається проекту, що знаходиться там, ми маємо правильну підмножину двійкових файлів на місці.

Що стосується відкриття часу та побудови часу, це буде важко виправити, не розбиваючись на менші рішення. Ви можете дослідити паралелізацію збірки (google "Parallel MS Build", як це зробити та інтегрувати в інтерфейс користувача), щоб тут покращити швидкість. Крім того, подивіться на дизайн і подивіться, чи може допомогти рефакторинг деяких ваших проектів, щоб узагальнити менше.

Що стосується полегшення болю в будівлі, ви можете використовувати опцію "Менеджер конфігурацій ..." для збірок, щоб увімкнути або вимкнути побудову конкретних проектів. Ви можете мати "Project [n] Build", який може виключати певні проекти і використовувати його, коли ви націлюєтесь на конкретні проекти.

Що стосується 100+ проектів, я знаю, що ви не хочете, щоб вас зачіпали цим питанням про переваги зменшення розміру вашого рішення, але я думаю, що у вас немає іншого варіанту, як це стосується прискорення часу завантаження (і використання пам'яті) devenv.

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

Тому після кожної збірки у мене є заповнена папка з усіма dll-файлами та будь-якими вікнами / веб-додатками, і всі елементи знаходяться у відповідному місці. Локальне копіювання не було потрібно, оскільки dll врешті опинився в потрібному місці.

Примітка

Вищезазначене працює для моїх рішень, які, як правило, є веб-додатками, і у мене не виникало жодних проблем із посиланнями, але це можливо!

У нас схоже питання. Ми вирішуємо це, використовуючи менші рішення. У нас є головне рішення, яке все відкриває. Але перф. на що погано. Отже, ми сегментуємо менші рішення за типом розробника. Отже, розробники БД мають рішення, яке завантажує проекти, які їх цікавлять, розробники сервісів та розробники інтерфейсу користувача те саме. Рідко, коли комусь доводиться відкривати ціле рішення, щоб виконувати те, що їм потрібно, щодня. Це не панацея - вона має і переваги, і мінуси. Див. "Модель з декількома рішеннями" у цій статті (проігноруйте частину про використання VSS :)

Я думаю, що для вирішення таких великих методів найкращою практикою має бути їх розбиття. Ви можете думати про "рішення" як про місце, де можна зібрати необхідні проекти та, можливо, інші елементи для роботи над вирішенням проблеми. Розбивши 100+ проектів на кілька рішень, що спеціалізуються на розробці рішень лише для однієї частини загальної проблеми, ви можете впоратися з меншим обсягом за певний час, пришвидшивши взаємодію з необхідними проектами та спростивши проблемну область.

Кожне рішення дасть результат, за який воно відповідає. Цей результат повинен містити інформацію про версію, яку можна встановити в автоматизованому процесі. Коли результат стабільний, ви можете оновити посилання у залежних проектах та рішеннях за допомогою останнього внутрішнього розподілу. Якщо ви все-таки хочете зайти в код і отримати доступ до джерела, ви можете насправді зробити це за допомогою сервера символів Microsoft, який Visual Studio може використовувати, щоб дозволити вам входити у збірки, на які посилаються, і навіть отримувати вихідний код.

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

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

Сподіваюся, ця інформація допоможе.

У нас близько 60+ проектів, і ми не використовуємо файли рішень. У нас поєднання проектів на C # та VB.Net. Виступ завжди був проблемою. Ми не працюємо над усіма проектами одночасно. Кожен розробник створює власні файли рішень на основі проектів, над якими працює. Файли рішення не перевіряються в нашому контролі джерел.

Усі проекти бібліотеки класів будуватимуться до папки CommonBin у кореневій папці джерела. Виконувані файли / веб-проекти будуються в окремій папці.

Ми не використовуємо посилання на проекти, натомість посилання на файли з папки CommonBin. Я написав спеціальне завдання MSBuild, яке перевіряло проекти та визначало порядок складання.

Ми використовуємо це вже кілька років і не маємо претензій.

Все пов’язано з вашим визначенням та поглядом на те, що таке рішення та проект. На мою думку, рішення - це саме це, логічне групування проектів, які вирішують дуже конкретні вимоги. Ми розробляємо великий додаток Інтранет. Кожна програма в цій Інтранеті має своє власне рішення, яке також може містити проекти для exes або служб Windows. І тоді ми маємо централізовану структуру з такими речами, як базові класи та помічники та httphandlers / httpmodules. Базова структура досить велика і використовується всіма програмами. Розділяючи багато рішень таким чином, ви зменшуєте кількість проектів, необхідних для рішення, оскільки більшість з них не мають нічого спільного між собою.

Наявність такої кількості проектів у рішенні - це просто поганий дизайн. Не повинно бути жодної причини для того, щоб стільки проектів було вирішено. Інша проблема, яку я бачу, - це посилання на проекти, вони можуть насправді зіпсувати вас, особливо якщо ви коли-небудь захочете розділити своє рішення на менші.

Моя порада - зробити це та розробити централізовану структуру (якщо ви хочете, власне впровадження Enterprise Library) Ви можете або обміняти його GAC, або можете безпосередньо вказати розташування файлу, щоб у вас був центральний магазин. Ви можете використовувати ту саму тактику і для централізованих бізнес-об'єктів.

Якщо ви хочете безпосередньо посилатися на DLL, ви хочете посилатися на неї у своєму проекті за допомогою copy local false (десь, наприклад c: \ mycompany \ bin \ mycompany.dll). Під час виконання вам потрібно буде додати деякі налаштування до вашого app.config або web.config, щоб зробити його посиланням на файл, який не знаходиться у GAC або контейнері виконання. Насправді не має значення, локальна вона копія чи ні, або dll потрапляє в смітник або навіть знаходиться в GAC, оскільки конфігурація замінить їх обидва. Я вважаю поганою практикою копіювати локальні файли та мати безладну систему. Швидше за все, вам доведеться тимчасово скопіювати локальний, якщо вам потрібно налагодити одну з цих збірок.

Ви можете прочитати мою статтю про те, як глобально використовувати DLL без GAC. Мені дуже не подобається GAC здебільшого тому, що він запобігає розгортанню xcopy і не викликає автоперезавантаження програм.

http://nbaked.wordpress.com/2010/03/28/gac-alternative/

Встановити CopyLocal = false зменшить час побудови, але може спричинити різні проблеми під час розгортання.

Існує багато сценаріїв, коли вам потрібно залишити Copy Local 'до True, наприклад, проекти верхнього рівня, залежності другого рівня, DLL, викликані за допомогою відображення.

Мій досвід налаштування CopyLocal = false не був успішним. Див. Короткий опис плюсів і мінусів у моєму дописі в блозі "НЕ змінюйте посилання на проект" Копіювати локально "на хибні, якщо не зрозуміти послідовності."