Добавление той же ссылки "*.dll" к нескольким проектам в том же решении

Ответ 1

Наконец-то я нашел решение этой проблемы, которая не похожа на хак. Я нашел ответ в ответ от "pyro_serv" на социальном сайте msdn:

Исправление состоит в том, чтобы использовать флаги "Использовать зависимости в сборке" и "Использовать в сборке" на каждой странице проекта VC (через лист свойств VC) и переключать их в соответствии с вашим случаем для устранения этой ошибки.

Итак, для примера OP, который выглядит примерно так:

Solution -> Log4.net
Solution -> Proj1
Solution -> Proj1 -> Log4.net
Solution -> Proj2
Solution -> Proj2 -> Log4.net
...

Чтобы избежать предупреждений, нужно установить Use Dependencies in Build в false для всех ссылок на Proj1,Proj2,..,Projn.

Я только что проверил это с демонстрационным решением, и он отлично работает - я не могу поверить, насколько просто решение и сколько времени я потратил, чтобы найти его!

Ответ 2

Измените ссылку на проекты, установите для всех свойств "copy local..." значение false.

Источник: http://developertips.blogspot.com/2008/07/ccli-warning-c4945.html

Ответ 3

У меня была такая же проблема. Это вызвано следующей ситуацией, когда проект зависит от другого проекта:

my_solution -> System.Xaml.dll -> System.dll
my_solution -> System.dll

Когда я удалил ссылку на System.dll(например), она решила предупреждение компилятора.

Ответ 4

У меня было такое же предупреждение в этой ситуации:

Solution:
 |
 |-> Project1 : Outdir = "C:\out"
 |
 |-> Project2 : Outdir = [default Outdir] // Was wrong in this case
 |
 |-> Project3 : Outdir = "C:\out"

Отношения зависимостей были следующими.

Solution -> Project1
Solution -> Project2 -> (Project1)
Solution -> Project3 -> (Project1, Project2)

Фиксация Project2 Outdir на "C:\out" (как и предполагалось, это был недавно созданный проект и забыл изменить его), зафиксировало предупреждение.

Ответ 5

У меня снова была такая же проблема сегодня.
Прежде всего, благодаря Jon Cage и связанной статье в его посте по этой теме, см. Выше (или ниже). +1!!! Он решил мою проблему.

Но поскольку я ненавижу такие вещи, как toggle them as appropriate for your case, что означает ничего, кроме trial and error, я провел несколько тестов, так как у меня есть 2 решения с большим количеством проектов С++/CLI в каждом.

Вот мои советы и объяснения:
Для всех сборщиков с самосозданием (которые имеют "скопировать локальный" в true):

"Общие свойства" → "Структура и ссылки" → "Ссылки" → Выберите ссылку.
В листе свойств справа → "Свойства сборки" → "Использование зависимостей при сборке"
- (скопировано из связанной статьи форума msdn сообщения Джона Кейджа)

Установите этот параметр Use Dependencies In Build на "false", сняв флажок.
Он работает как "эталонная переадресация", см. Пример ниже.

ТЕХНИЧЕСКАЯ СПРАВКА:
- > означает "ссылки"
метод 1:
в моем решении SwCore:
A.1.1 network->tools, A.1.2 network->basics.
A.2.1 tools->basics.
A.3.1 drives->basics, A.3.2 drives->tools, A.3.3 drives->network
A.4.1...
с "Use Dependencies In Build", установленным в true, ссылка A.1.2 может быть опущена, так как она включена в A.2.1.
все файлы создаются в swcore\release\
== проблема:
в решении DDI:
B.1.1 DDI_hardware->DDI_job, B.1.2 DDI_hardware->drives
B.2.1 DDI_job->basics, B.2.2 DDI_job->tools, B.2.3 DDI_job->job
DDI_job создается в DDI\Release\и с "U.D.InBuild" установлен в true, он включает basics.
DDI_hardware создается... и с "U.D.InBuild" установлено значение true, оно включает DDI_job->basics.
DDI_hardware также ссылается на основы от SwCore\Release\
== > двойная ссылка на основы и другие. VS видит 2 файла и не может понять, что это одно и то же содержимое.

метод 2:
A.1.1 network->tools, A.1.2 network->basics.
A.2.1 tools->basics.
с установкой "U.D.InBuild" в FALSE, ссылка A.1.2 НЕ может быть опущена, поскольку она не переадресована из A.2.1.
== работает, потому что никакая сборка не будет содержать другие более глубокие зависимости, поэтому конфликтов не будет.

BTW: Это заставляет вас указывать все необходимые ссылки для каждого проекта, поэтому вы также можете ознакомиться с тем, что вы используете в своем проекте.

Последняя информация: Я не могу точно сказать, если мои объяснения верны. Может быть и так. else может подтвердить.