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

Question

У меня есть решение Visual Studio 2008 .NET C ++ / CLI.Мое решение состоит из множества подпроектов.Я определяю пользовательский каталог buid для каждого проекта и называю его Выход.

... MyNthProject (* .dll)

Каждый из подпроектов использует Log4.net. Поэтому я создаю каталог (называемый LogBinary) и помещаю log4.net dll в этой папке. Затем, чтобы использовать log4net, я добавляю эту dll как ссылку на каждый мой проект ... Но когда я пытаюсь скомпилировать свой основной проект (* .exe), я получаю тонны предупреждений (более 400 ...)

Просто пример:

Предупреждение 110 Предупреждение C4945: «AbsoluteTimeDateFormatter»: не может импортировать символ из «somepath \ log4net.dll»:как 'log4net :: DateFormatter :: AbsoluteTimeDateFormatter' уже импортирован из другой сборки 'log4net' "somepath \ log4net.dll"

Много предупреждений с

уже импортировано из другой сборки

Почему я получил это предупреждение?Есть ли у кого-нибудь элегантное решение, чтобы добавить одну и ту же DLL в несколько проектов (кроме использования GAC)

С наилучшими пожеланиями

Answer 1

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

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

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

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

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

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

Answer 2

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

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

Answer 3

Сегодня у меня снова возникла та же проблема.
Прежде всего, благодаря Джону Кейджу и связанной статье в его сообщении в этой теме, см. Выше (или ниже) .+1 !!!Это решило мою проблему.

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

Вот мой совет и объяснение этого:
Для всех «самостоятельно созданных» сборок (для которых «copy local» установлено в true):

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

Установите для этого параметра Use Dependencies In Build значение "false", сняв отметку.
Он работает как "пересылка ссылок", см. примерниже.

ТЕХНИЧЕСКИЙ ФОН:
-> означает «ссылки»
метод 1:
в моем решении SwCore:
A.1.1 network->tools,А.1.2 network->basics.
А.2.1 tools->basics.
А.3.1 drives->basics, А.3.2 drives->tools, А.3.3 drives->network
А.4.1 ...
с параметром "Использовать зависимости в сборке", установленным в true, ссылка A.1.2 может быть опущена, так как она включена в A.2.1.
все файлы создаются в swcore \ release \
== problem:
в растворе 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 \ и с помощью "UDInBuild"Значение true, оно включает в себя basics.
DDI_hardware, созданное ... и если для UDInBuild установлено значение 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.
с "UDInBuild", установленным в FALSE, ссылка A.1.2 НЕ МОЖЕТ быть пропущена, поскольку она не пересылается из A.2.1.
== работаетпотому что ни одна сборка не будет содержать других более глубоких зависимостей, поэтому не будет конфликтов.

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

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

Answer 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" (как на самом деле предполагалось, это был недавно созданный проект и забыл его изменить) исправило предупреждение.

Answer 5

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

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

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