Нещодавно на роботі ми зіткнулися з проблемою, коли ми помітили / розгалужили проект і мали деякі проблеми зі збиранням через посилання на dll / проект, що вказувало на стару структуру папок.
Ми створили папку «зовнішня скринька» для кожного з проектів і скопіювали посилання з вказаними dll у ці папки. Це найкращий спосіб чи є певний галузевий стандарт для вирішення цього питання?
Відповіді:
Я б сказав, що « нугет» - це найкращий спосіб впоратися із залежностями.
nuget може керувати версіями І автоматично завантажувати залежності з вашого локального сервера.
Створити / налаштувати локальний сервер досить просто. Просто створіть новий порожній проект ASP.NET та встановіть nuget-serverпакет nuget (використовуючи nuget;).
Це також означає, що вам не доведеться перевіряти всі залежності та / або керувати їх версіями за допомогою TFS.
Насправді це не так - Microsoft каже, що найкращим способом обробки посилань є побудова проекту в одному величезному рішенні. Так, я знаю, вони теж насправді означають це.
Команда з моделей та практик поєднала свої найкращі практики стосовно ТФС, але це стосується загальних побудов. Існує 3 типи налаштування рішення, «1 велике рішення», розділений підхід, який дуже схожий на те, як більшість людей використовували для управління побудови, будуючи по черзі і копіюючи артефакти в загальний каталог (який не допомагав .NET не маючи на сервері шлях "включати" або "бібліотеку" до посилання) та налаштування декількох рішень, яка є більш складною версією розділеної версії.
Вони кажуть
In general you should:
Use a single solution strategy unless the resulting solution is too large to load into Visual Studio.
Use multiple solutions to create specific views on sub-systems of your application.
Use multiple solutions to reduce the time it takes to load a solution and to reduce build time for developers.Для TFS вони рекомендують розгалужувати будь-які зовнішні проекти всередині вашого проекту, а не покладатися на відображення робочого простору, яке більше схоже на зовнішні підривні процеси. Особисто я вважаю, що їхні поради не є найкращою практикою, але я припускаю, що вони намагаються мінімізувати будь-які проблеми зі збиранням, які ви отримаєте при використанні посилань.
У мене виникли проблеми з .NET-побудовами, які намагаються скоротити систему, будуючи лише те, що потрібно, нічна збірка, яка робить усе, і копіює кожну нову збірку в каталог, була найкращим способом для синхронізації - особливо тестерів. Зауважте, це дійсно стосується лише програм .NET, C ++, як правило, все ще працюють, оскільки у них немає збірних версій або подібних аспектів, які можуть викликати проблеми з викликом компонентів. Такий підхід працює добре, але ви не завжди можете припустити, що часткове нарощування нормально, перетворення всієї справи та відновлення є найбезпечнішим.
Це залежить від структури вашого рішення та можливостей програмного забезпечення для управління версіями. Раніше ми використовували для того, щоб не вбудований / пропущений проект у наших рішеннях містив документацію та папку спеціально для будь-яких сторонніх бібліотек. Оскільки воно було частиною рішення, шлях до цих файлів може бути посилається за допомогою відносного шляху. Після того, як ми перейшли до TFS 2010, ми позбулися цього проекту і просто додали каталог «Підтримка» в папку цього рішення в командному проекті паралельно нашим головним гілкам. У будь-якому випадку версія джерела управління бібліотекою опиняється в тому самому місці відносно незалежно від того, як налаштовано розробники своїх машин.
Використовуючи підрив для контролю версій, ви можете використовувати для цього властивість "зовнішні" . Це дозволяє зберігати локальну копію спільної DLL у відносному шляху поблизу поточного проекту. Це полегшує посилання на DLL по відносному шляху файлу, який не змінюється, навіть коли ви змінюєте основний каталог свого проекту в іншу папку. Зовнішні особи дозволяють вам також визначити, яку саме версію чи версію включити.