Яка найкраща практика для "Копіювання місцевих" та посилань на проекти?

У мене є великий файл рішення c # (~ 100 проектів), і я намагаюся покращити час збирання. Я думаю, що "Копіювати місцеве" в багатьох випадках для нас марно, але мені цікаво найкращим методом.

У нашому .sln у нас є додаток A залежно від складання B, яке залежить від складання C. У нашому випадку є десятки "B" і жменька "C". Оскільки всі вони включені у .sln, ми використовуємо посилання на проекти. Наразі всі збірки вбудовані у $ (SolutionDir) / Debug (або Release).

За замовчуванням Visual Studio позначає ці посилання на проект як "Copy Local", в результаті чого кожен "C" копіюється в $ (SolutionDir) / Debug один раз для кожного "B", який створюється. Це здається марнотратним. Що може піти не так, якщо я просто відключу "Copy Local"? Що роблять інші люди з великими системами?

СЛІДУВАТИ:

Дуже багато відповідей пропонують розділити збірку на менші .sln файли ... У наведеному вище прикладі я спочатку побудую основні класи "C", а потім основну частину модулів "B", а потім декілька додатків " А ". У цій моделі мені потрібно мати непроектні посилання на C від B. Проблема, з якою я стикаюся, полягає в тому, що "Налагодження" або "Випуск" потрапляє в підказковий шлях, і я закінчую будівництво моїх версій "B" проти налагодження складання "C".

Для тих, хто розділяє збірку на кілька .sln файлів, як ви керуєте цією проблемою?

У попередньому проекті я працював з одним великим рішенням із посиланнями на проект і натрапив на проблему ефективності. Розчин був триразовим:

1. Завжди встановлюйте властивість Copy Local на значення false та застосовуйте це за допомогою спеціального кроку msbuild

2. Встановіть вихідний каталог для кожного проекту в один і той же каталог (бажано відносно $ (SolutionDir)

3. Цілі cs за замовчуванням, які постачаються разом з рамкою, обчислюють набір посилань, які потрібно скопіювати у вихідний каталог проекту, який наразі будується. Оскільки для цього потрібно обчислити перехідне закриття у співвідношенні "Посилання", це може стати ДУЖЕ дорогим. Моє вирішення цього завдання полягало в тому, щоб переосмислити GetCopyToOutputDirectoryItemsціль у загальному файлі цілей (напр. Common.targets), Який імпортується у кожен проект після імпорту Microsoft.CSharp.targets. У результаті кожен файл проекту виглядає наступним чином:

   <Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
     <PropertyGroup>
       ... snip ...
     </ItemGroup>
     <Import Project="$(MSBuildBinPath)\Microsoft.CSharp.targets" />
     <Import Project="[relative path to Common.targets]" />
     <!-- To modify your build process, add your task inside one of the targets below and uncomment it. 
          Other similar extension points exist, see Microsoft.Common.targets.
     <Target Name="BeforeBuild">
     </Target>
     <Target Name="AfterBuild">
     </Target>
     -->
   </Project>
   

Це скоротило наш час збирання за певний час від пари годин (в основному через обмеження пам’яті), до пари хвилин.

Redefined GetCopyToOutputDirectoryItemsможе бути створений шляхом копіювання ліній 2,438-2,450 і 2,474-2,524 з C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Microsoft.Common.targetsв Common.targets.

Для повноти отримане цільове визначення потім стає:

<!-- This is a modified version of the Microsoft.Common.targets
     version of this target it does not include transitively
     referenced projects. Since this leads to enormous memory
     consumption and is not needed since we use the single
     output directory strategy.
============================================================
                    GetCopyToOutputDirectoryItems

Get all project items that may need to be transferred to the
output directory.
============================================================ -->
<Target
    Name="GetCopyToOutputDirectoryItems"
    Outputs="@(AllItemsFullPathWithTargetPath)"
    DependsOnTargets="AssignTargetPaths;_SplitProjectReferencesByFileExistence">

    <!-- Get items from this project last so that they will be copied last. -->
    <CreateItem
        Include="@(ContentWithTargetPath->'%(FullPath)')"
        Condition="'%(ContentWithTargetPath.CopyToOutputDirectory)'=='Always' or '%(ContentWithTargetPath.CopyToOutputDirectory)'=='PreserveNewest'"
            >
        <Output TaskParameter="Include" ItemName="AllItemsFullPathWithTargetPath"/>
        <Output TaskParameter="Include" ItemName="_SourceItemsToCopyToOutputDirectoryAlways"
                Condition="'%(ContentWithTargetPath.CopyToOutputDirectory)'=='Always'"/>
        <Output TaskParameter="Include" ItemName="_SourceItemsToCopyToOutputDirectory"
                Condition="'%(ContentWithTargetPath.CopyToOutputDirectory)'=='PreserveNewest'"/>
    </CreateItem>

    <CreateItem
        Include="@(_EmbeddedResourceWithTargetPath->'%(FullPath)')"
        Condition="'%(_EmbeddedResourceWithTargetPath.CopyToOutputDirectory)'=='Always' or '%(_EmbeddedResourceWithTargetPath.CopyToOutputDirectory)'=='PreserveNewest'"
            >
        <Output TaskParameter="Include" ItemName="AllItemsFullPathWithTargetPath"/>
        <Output TaskParameter="Include" ItemName="_SourceItemsToCopyToOutputDirectoryAlways"
                Condition="'%(_EmbeddedResourceWithTargetPath.CopyToOutputDirectory)'=='Always'"/>
        <Output TaskParameter="Include" ItemName="_SourceItemsToCopyToOutputDirectory"
                Condition="'%(_EmbeddedResourceWithTargetPath.CopyToOutputDirectory)'=='PreserveNewest'"/>
    </CreateItem>

    <CreateItem
        Include="@(Compile->'%(FullPath)')"
        Condition="'%(Compile.CopyToOutputDirectory)'=='Always' or '%(Compile.CopyToOutputDirectory)'=='PreserveNewest'">
        <Output TaskParameter="Include" ItemName="_CompileItemsToCopy"/>
    </CreateItem>
    <AssignTargetPath Files="@(_CompileItemsToCopy)" RootFolder="$(MSBuildProjectDirectory)">
        <Output TaskParameter="AssignedFiles" ItemName="_CompileItemsToCopyWithTargetPath" />
    </AssignTargetPath>
    <CreateItem Include="@(_CompileItemsToCopyWithTargetPath)">
        <Output TaskParameter="Include" ItemName="AllItemsFullPathWithTargetPath"/>
        <Output TaskParameter="Include" ItemName="_SourceItemsToCopyToOutputDirectoryAlways"
                Condition="'%(_CompileItemsToCopyWithTargetPath.CopyToOutputDirectory)'=='Always'"/>
        <Output TaskParameter="Include" ItemName="_SourceItemsToCopyToOutputDirectory"
                Condition="'%(_CompileItemsToCopyWithTargetPath.CopyToOutputDirectory)'=='PreserveNewest'"/>
    </CreateItem>

    <CreateItem
        Include="@(_NoneWithTargetPath->'%(FullPath)')"
        Condition="'%(_NoneWithTargetPath.CopyToOutputDirectory)'=='Always' or '%(_NoneWithTargetPath.CopyToOutputDirectory)'=='PreserveNewest'"
            >
        <Output TaskParameter="Include" ItemName="AllItemsFullPathWithTargetPath"/>
        <Output TaskParameter="Include" ItemName="_SourceItemsToCopyToOutputDirectoryAlways"
                Condition="'%(_NoneWithTargetPath.CopyToOutputDirectory)'=='Always'"/>
        <Output TaskParameter="Include" ItemName="_SourceItemsToCopyToOutputDirectory"
                Condition="'%(_NoneWithTargetPath.CopyToOutputDirectory)'=='PreserveNewest'"/>
    </CreateItem>
</Target>

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

Я пропоную вам прочитати статті Патрика Смакіа на цю тему:

• Розбиття бази Вашого коду за допомогою .NET зборів та проектів Visual Studio -> Чи повинен кожен проект Visual Studio дійсно мати власну збірку? І що насправді означає "Копіювати локальне = Істинне"?
• Уроки, отримані з бази коду NUnit -> Довідка проекту VisualStudio + Копіювати місцевий правдивий варіант - це зло! )
• Аналіз бази коду CruiseControl.NET -> Неправильне використання опції "Копіювати локальну довідкову збірку " встановлено на True)

Проекти CC.Net VS покладаються на параметр складання локальної довідкової копії, встановлений на true. [...] Це не тільки значно збільшить час компіляції (x3 у випадку з NUnit), але й зіпсує ваше робоче середовище. І останнє, але не менш важливе, це вводить ризик для версії потенційних проблем. Btw, NDepend надсилатиме попередження, якщо він знайде 2 збірки у двох різних каталогах з однаковою назвою, але не однакового змісту чи версії.

Правильно зробити, це визначити 2 каталоги $ RootDir $ \ bin \ Debug та $ RootDir $ \ bin \ Release та налаштувати ваші проекти VisualStudio для випромінювання збірок у цих каталогах. Усі посилання на проекти повинні посилатися на збірки в каталозі налагодження.

Ви також можете прочитати цю статтю, яка допоможе вам зменшити кількість проектів та покращити час складання.

Я пропоную скопіювати локальний = false для майже всіх проектів, крім того, який знаходиться у верхній частині дерева залежності. І для всіх посилань у тому, що знаходиться зверху, копіюйте local = true. Я бачу багато людей, які пропонують поділитися вихідним каталогом; Я думаю, що це жахлива ідея, заснована на досвіді. Якщо ваш стартовий проект містить посилання на dll, що будь-який інший проект містить посилання на вас, у якийсь момент ви відчуєте порушення доступу / спільного використання, навіть якщо копіювати локальне = false у всьому, і ваша збірка не вдасться. Це питання дуже дратує і важко відстежити. Я повністю пропоную триматися подалі від каталогу вихідних фрагментів і замість того, щоб мати проект у верхній частині ланцюга залежностей, записати необхідні збірки у відповідну папку. Якщо у вас немає проекту вгорі, то я б запропонував копію після складання, щоб все було в потрібному місці. Крім того, я б намагався мати на увазі простоту налагодження. Будь-які проекти EXE, я все ще залишаю копію local = true, щоб досвід налагодження F5 працював.

Ви праві. CopyLocal абсолютно вбиває ваші строки збирання. Якщо у вас є велике дерево джерела, вам слід відключити CopyLocal. На жаль, це не так просто, як це повинно бути чисто відключити. Я відповів на це точне запитання щодо відключення функції CopyLocal на сторінці Як перекрити налаштування CopyLocal (Private) для посилань у .NET від MSBUILD . Перевір. А також кращі практики для великих рішень у Visual Studio (2008).

Ось додаткова інформація про CopyLocal, як я бачу.

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

Я писав про те, як боротися зі створенням дерев великих джерел у статті MSBuild: Найкращі практики створення надійних будівель, частина 2 .

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

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

/ p: CreateHardLinksForAdditionalFilesIfPossible = true; CreateHardLinksForCopyAdditionalFilesIfPossible = true; CreateHardLinksForCopyFilesToOutputDirectoryIfPossible = true; CreateHardLinksForCopyLocalIfPossible = true; CreateHardLinksForPPlive = True true; CreateHardLinksForPPlified

Ви також можете додати це до файлу центрального імпорту, щоб усі ваші проекти також могли отримати цю перевагу.

Якщо ви отримали структуру залежності, визначену за допомогою посилань на проект або через залежність від рівня рішення, можна безпечно повернути "Copy Local", я б навіть сказав, що це найкраща практика, тому що це дозволить вам використовувати MSBuild 3.5 для паралельного запуску збірки ( via / maxcpucount) без різних процесів, що перемикаються один на одного при спробі копіювання посилань.

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

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

Ви можете автоматизувати крок "копіювання збірки в матричний каталог" за допомогою візуальних макросів студії або за допомогою "меню -> інструменти -> зовнішні інструменти ...".

Вам не потрібно змінювати значення CopyLocal. Все, що вам потрібно зробити, - це заздалегідь визначити загальний $ (OutputPath) для всіх проектів у рішенні та встановити $ (UseCommonOutputDirectory) на true. Дивіться це: http://blogs.msdn.com/b/kirillosenkov/archive/2015/04/04/using-a-common-intermediate-and-output-directory-for-your-solution.aspx

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

Існує багато сценаріїв, коли потрібно, щоб Copy Local 'залишилося в True, наприклад,

• Проекти вищого рівня,
• Залежності другого рівня,
• DLL, викликані відображенням

Можливі проблеми, описані в питаннях SO:
" Коли слід встановити локальну копію для true та коли її немає? ",
" Повідомлення про помилку" Неможливо завантажити один або декілька запитуваних типів. Для отримання додаткової інформації отримайте властивість LoaderExceptions. " "
І   Арон-stainback « s відповідь  на це питання.

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

Час вирішення проблем надмірно важить переваги встановлення copyLocal = false.

Я схильний створювати загальний каталог (наприклад, .. \ bin), тому можу створити невеликі тестові рішення.

Ви можете спробувати скористатися папкою, куди будуть скопійовані всі збірки, які спільно використовуються між проектами, потім зробіть змінну середовища DEVPATH та встановіть

<developmentMode developerInstallation="true" />

у файл machine.config на робочій станції кожного розробника. Єдине, що вам потрібно зробити - це скопіювати будь-яку нову версію у свою папку, де точки DEVPATH змінні.

Також розділіть своє рішення на кілька менших рішень, якщо можливо.

Це може бути не найкращим способом, але я працюю так.

Я помітив, що керований C ++ скидає всі свої двійкові файли в $ (SolutionDir) / 'DebugOrRelease'. Тому я також скинув усі свої C # проекти. Я також вимкнув "Copy Local" всіх посилань на проекти в рішенні. У своєму маленькому 10 проектному рішенні я помітно покращив час побудови. Це рішення являє собою суміш C #, керованого C ++, нативного C ++, C # веб-сервісу та інсталяторських проектів.

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

Було б цікаво дізнатися, що я ламаю.

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

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

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

Здавалося б дивним, якби всі 100 проектів покладалися один на одного, тож вам слід мати змогу або розбити його, або скористатися програмою Configuration Manager, щоб допомогти собі.

Ви можете мати посилання на свої проекти, що вказують на версії налагодження DLL. Тоді як у вашому скрипті msbuild ви можете встановити /p:Configuration=Release, таким чином, у вас буде версія версії програми та всіх супутникових збірок.

Якщо ви хочете мати центральне місце для посилання на DLL, використовуючи локальну помилку копіювання, без GAC не вдасться, якщо ви цього не зробите.

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

Якщо посилання не міститься в GAC, ми повинні встановити місце локального копіювання на true, щоб програма працювала, якщо ми впевнені, що посилання буде попередньо встановлено в GAC, то воно може бути встановлено на false.

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

• c: папка рішення \ bin -> ramdisk r: \ папка рішення \ bin \

• c: папка рішення \ obj -> ramdisk r: \ папка рішення \ obj \

• Ви також можете сказати візуальній студії, який тимчасовий каталог він може використовувати для збирання.

Насправді це було не все, що він робив. Але це дійсно вразило моє розуміння продуктивності.
100% використання процесорів та величезний проект за 3 хвилини з усіма залежностями.