Як структурувати кілька перекриваються рішень / проектів у .Net?

Нещодавно я почав працювати над новим клієнтом зі старою застарілою базою кодів, в якій є безліч .net-рішень, кожен зазвичай розміщує деякі проекти, унікальні для цього рішення, але потім "запозичує" / "посилається" (додайте існуючий проект) деякі інші проекти який технічно належить до інших рішень (принаймні, якщо ви переходите до структури папок у TFS)

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

Схоже, все оптимізовано для лінь розробників.

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

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

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

• Як структурувати код у VCS
• Як полегшити обмін діловою логікою між окремими артефактами розгортання

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

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

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

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

Бінарні посилання на вихід інших каталогів не є хорошим підходом, і стає поганим підходом при взаємодії з посиланнями на проекти. Спробуйте зробити те чи інше, бажано змінивши свої бінарні посилання на проектні пропозиції на узгодження як мінімум. На цьому етапі кожне рішення може представляти собою єдиний рівень програми чи додатка (наприклад, SuperApp.sln, OtherAppServices.sln, OtherAppPresentationTier.sln).

Для створення ВСІХ проектів рекомендую також створити Master Solution. Основне рішення матиме посилання на проект на все і по суті існує з єдиною вигодою, щоб мати єдину команду збірки, яка обробляє всі проекти в наборі програм. Розробники не повинні використовувати головне рішення для активної розробки або налагодження. Це значно спрощує збірку артефактів збірки.

Потім розгортання може бути виконано за допомогою простого пакета, паттерну або скрипту Perl. Це по суті створить відповідне рішення або головне рішення, а потім все розгорне у відповідні середовища. Це можна легко інтегрувати в будь-який сервер CI, якщо зробити все правильно.

• Як полегшити обмін бізнес-логікою між окремими артефактами розгортання

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

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