Поместите все выходные библиотеки в общий каталог из Visual Studio
У меня есть несколько разных решений, в которых некоторые проекты могут зависеть от результатов других проектов. Чтобы справиться с этим, я копировал dll-файлы из папки / bin / в каждом проекте в общую библиотеку после сборки, а затем копировал / ссылал их оттуда в зависимый проект.
Однако, по мере того, как библиотечное решение становится больше, это становится недостижимым. Слишком много времени я трачу на просмотр каталогов решений в проводнике Windows в поисках папок / bin / и на выяснение того, какие или какие из dll-файлов мне нужны.
Есть ли способ дать Visual Studio подсказку, что я хочу, чтобы все проекты в решении имели одинаковый выходной каталог? Например, папка / bin / находится прямо в папке решения, в которую выводятся все проекты.
Если возможно, я бы хотел добиться этого без жестко запрограммированных событий после сборки, которые копируют файлы, поскольку это не удастся, если выходные данные проекта изменят имя файла или добавят другой файл. Я бы предпочел изменить местоположение фактического выходного каталога - расположение $(OutDir), если хотите.
2 ответа
Вы можете установить выходной каталог в свойствах каждого проекта.
Щелкните правой кнопкой мыши на проекте, выберите Properties
Для C# это один из Build страница свойств, под Output, Output directory,
В проектах VB.Net он находится на Compile вкладка, в текстовом поле вверху.
Я знаю, что вы сказали, что не хотите использовать события после сборки, но ваша причина почему меня не заинтриговала. Похоже, что вы можете быть трудно кодировать имя.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. Теперь будет 2 копии файла HtmlParser.dll в каталоге c: \ common.
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