Поместите все выходные библиотеки DLL в общий каталог Visual Studio.

Question

У меня есть несколько разных решений, в которых некоторые проекты могут зависеть от результатов проектов в других решениях.Чтобы справиться с этим, я копировал файлы DLL из папки /bin/ в каждом проекте в папку общей библиотеки после сборки, а затем копировал их оттуда или ссылался на них в зависимый проект.

Однако по мере того, как библиотечное решение становится больше, его поддержка становится невозможной.Слишком много времени я трачу на просмотр каталогов решений в проводнике Windows в поисках папок /bin/ и на попытки выяснить, какой из dll-файлов из каждого из них мне нужен.

Есть ли способ дать Visual Studio подсказку, которую я хочу? все проекты в решении имеют один и тот же выходной каталог?Например, папка /bin/ непосредственно в папке решения, где все проекты ставят свои результаты.

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

Answer 1

Вы можете задать выходной каталог в свойствах каждого проекта.

Щелкните правой кнопкой мыши на проекте, выберите Properties

Для C # это один из Build страница свойств в разделе Output, Output directory.

В VB.Net projects он находится на Compile вкладка в текстовом поле вверху.

Answer 2

Я знаю, вы сказали, что не хотите использовать события после сборки, но ваша причина, почему это не заинтриговала меня.Похоже, вы жестко запрограммировали имя .dll в событии после сборки.Этого можно легко избежать.

xcopy "$(TargetDir)*" "c:\common\" /Y

А * просто вызвало бы все в папке bin/Debug/, чтобы скопировать его в общую папку.Вы также можете просто скопировать библиотеки DLL, если хотите.Или, если вы используете $(TargetPath), вы скопируете только 1 dll, являющуюся результатом проекта, а не какие-либо другие связанные зависимости.

ОБНОВЛЯТЬ

Мы делаем это так: вся папка bin каждого проекта копируется в субпапка.Предположим, у вас есть 2 проекта, WebUtil и HtmlParser, где WebUtil зависит от HtmlParser.Для обоих проектов используйте xcopy "$(TargetDir)*" "c:\common\$(ProjectName)" /Y.Это создаст c:\common\WebUtil\ и c:\common\HtmlParser.В WebUtil добавьте ссылку на c:\common\HtmlParser\HtmlParser.dll.Теперь в папке c:\common будет две копии HtmlParser.dll.

c:\common\HtmlParser\HtmlParser.dll // самая последняя сборка.c:\common\WebUtil\HtmlParser // что был самая последняя сборка, когда был создан WebUtil

Это имеет массу преимуществ.Если вы измените API HtmlParser, WebUtil продолжит работать, поскольку у него будет более старая версия HtmlParser.dll, пока вы не попытаетесь пересобрать WebUtil (в этот момент вы получите ошибки сборки из-за измененного API).

Теперь, если в смесь попал третий проект, который зависел от WebUtil, и вы используете некоторую часть WebUtil, которая предоставляет классы в HtmlParser, вам нужно будет добавить ссылку на оба проекты из вашего нового проекта.Добавляя ссылку на HtmlParser.dll, используйте ссылку в c:\common\WebUtil.Вы делаете это потому, что включаете это только как необходимое требование WebUtil.Теперь у вас всегда будет версия HtmlParser.dll, соответствующая текущей версии WebUtil.dll.

Надеюсь это имеет смысл.Это определенно может быть сложной задачей.Просто подождите, пока вам не придется начать удалять все ваши зависимости, используя svn:externals =P.