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

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

5 голосов
/ 28 января 2009

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

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

Ответы [ 3 ]

4 голосов
/ 28 января 2009

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

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

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

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

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

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

1 голос
/ 02 февраля 2009

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

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

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

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

0 голосов
/ 28 января 2009

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

...