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

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

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

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

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


person Tomas Aschan    schedule 21.07.2010    source источник


Ответы (2)


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

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

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

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

person Oded    schedule 21.07.2010
comment
Мои проекты в основном представляют собой проекты VB.NET, поэтому страницы свойств выглядят не так, как для проектов C#. - person Tomas Aschan; 21.07.2010
comment
Все равно нашел =) Впрочем, это на уровне проекта. Что произойдет, если два проекта будут иметь зависимости от одного и того же стороннего проекта или сторонней dll — будут ли они перезаписаны, переименованы или будут звать на помощь (т. е. вызывать исключения)? Что мне нужно, так это - есть ли способ сделать это на уровне решения, а не на уровне проекта? - person Tomas Aschan; 21.07.2010
comment
@ Томас - да, на уровне проекта. Исключения не будут выдаваться, и обычно библиотеки DLL, которые являются зависимостями, будут перезаписаны. Это не проблема, так как компиляция проектов идет последовательно. - person Oded; 21.07.2010

Я знаю, вы сказали, что не хотите использовать события после сборки, но ваша причина, по которой я не заинтригован. Похоже, вы можете жестко запрограммировать имя .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 будет 2 копии 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

person Samuel Meacham    schedule 21.07.2010
comment
Это по-прежнему оставляет меня с одной из двух проблем: либо (если я скопирую все из корзины), я рискую скопировать слишком много и перезаписать материал из других проектов, либо (если я скопирую только dll, которая является результатом проекта) я рискую закончить слишком мало в папке builds, так как необходимые зависимости могут быть опущены. Срединного пути нет? - person Tomas Aschan; 21.07.2010
comment
+1 это именно то, что я бы предложил. @ Томас, ты понимаешь, что можешь еще более тщательно отфильтровать копию: xcopy "$(TargetDir)*.dll" "c:\common\" /Y копировать только dll. Если это не совсем понятно, вы можете добавить еще одну более конкретную команду копирования. На самом деле это не так уж и сложно, это всего пара минут работы и одна или две тестовые сборки, и если вы примените правильную фильтрацию к xcopy, то это также потребует минимального обслуживания. - person slugster; 21.07.2010
comment
@Tomas - вместо этого вы можете использовать Robocopy и использовать параметры исключения/включения, чтобы обойти эти сценарии. - person Hobo Spider; 05.10.2012