Оптимизация сборки решения Visual Studio — куда поместить DLL-файлы?

Я обнаружил, что время сборки решения C # со многими проектами становится намного быстрее, если у вас не включено «копировать локально» везде. Я провел несколько тестов, и кажется, что (по крайней мере, для нашего решения) мы можем увеличить время сборки в 2-3 раза, просто удалив «Копировать локально». Вероятно, это означает, что мы должны хранить библиотеки в каком-то общем каталоге.

Любые предложения/лучшие практики, как этого достичь? Обратите внимание, что я хотел бы сохранить ссылки на проекты, а не на библиотеки DLL.


build c# msbuild visual-studio-2008
person bh213    schedule 28.01.2009    source источник

Ответы (3)


arrow_upward
4
arrow_downward

Мы переназначаем выходной каталог проектов на ../../Debug (или ../../Release). Наши библиотеки также размещаются в этих каталогах.

Мы устанавливаем ссылочные пути в каждом проекте соответственно для каталога Debug или Release (этот параметр сохраняется в пользовательских файлах, поскольку это абсолютная, а не относительная ссылка).

Мы сохраняем ссылки на проекты как ссылки на проекты. Все ссылки на dll имеют локальную копию false и конкретную версию false, если только они не являются dll системного уровня, о которых мы знаем, что они будут в GAC на всех развернутых машинах.

Это работает, и ручная сборка в IDE имитирует сборку по сценарию из командной строки (с использованием MSBuild).

Тестовые проекты, не предназначенные для развертывания, не направляют свои выходные данные в централизованный каталог Debug|Release, они просто используют стандартное расположение по умолчанию (и используют локальное копирование, чтобы избежать проблем с блокировкой).

Версии библиотек могут быть изменены в процессе автоматической сборки, заменяющей библиотеки DLL в каталогах Debug и Release.

person ShuggyCoUk    schedule 28.01.2009

arrow_upward
1
arrow_downward

Я рекомендую сборку в ..\..\Build, если ваше приложение распределено между решениями. (Если у вас есть только одно решение, вы можете подумать о ..\Build.) Visual Studio по умолчанию подберет справочные файлы в своей выходной папке. Однако при сборке без VS с использованием MSBuild вы должны добавить папку сборки в качестве пути ссылки, как показано в примере ниже:

  <Target Name="BuildApp">
    <MSBuild
        Projects="@(ProjectReference)"
        Targets="Rebuild"
        Properties="ReferencePath=..\..\Build;$(LibraryFolder)" >
    </MSBuild>
    <OnError ExecuteTargets="BuildFailed" />
  </Target>

Этот пример также подводит меня ко второму аргументу. Я не думаю, что вы должны использовать свою папку сборки в качестве папки библиотеки, так как это может привести к тому, что отдельные проекты ошибочно перезапишут сборки библиотек, например. с помощью локального копирования. У вас должен быть строгий контроль над версиями вашей библиотеки, поэтому я предлагаю вам держать это отдельно. (Разработчикам потребуется добавить этот путь в VS в качестве эталонного пути.)

Вы также можете разделить ..\..\Build на ..\..\Release и ..\..\Debug как предложено ShuggyCoUk.

person Magnus Akselvoll    schedule 02.02.2009

arrow_upward
0
arrow_downward

Мне нравится установка папки Bin Lib верхнего уровня, которая распространена в системах на основе Unix, кстати, переход на этот тип системы также значительно облегчит жизнь вашему релиз-инженеру. Создание установщика значительно упрощается, так как нужно всего лишь вытащить все из одной папки. Затем Dll отправится в мусорное ведро.

person Alex    schedule 28.01.2009