Поместите все выходные библиотеки в общий каталог из Visual Studio - PullRequest
4 голосов
/ 21 июля 2010

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

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

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

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

Ответы [ 2 ]

7 голосов
/ 21 июля 2010

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

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

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

UPDATE

Как мы это делаем, каждый проект копирует всю папку bin в папку sub .Предположим, у вас есть 2 проекта, WebUtil и HtmlParser, где WebUtil зависит от HtmlParser.Для обоих проектов используйте xcopy "$(TargetDir)*" "c:\common\$(ProjectName)" /Y.Это создаст c: \ common \ WebUtil \ и c: \ common \ HtmlParser.В WebUtil добавьте ссылку на c: \ common \ HtmlParser \ HtmlParser.dll.Теперь будет две копии файла 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

3 голосов
/ 21 июля 2010

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

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

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...