Зависимости ссылок, не копируемых в выходной каталог
У меня есть библиотека CommonUtils, встроенная в dll, на которую я ссылаюсь в нескольких своих проектах. CommonUtils зависит от log4net.dll, который был установлен как ссылка на файл, и copy-local = true при сборке CommonUtils.dll. log4net.dll и CommonUtils.dll отсутствуют в GAC.
Все работает нормально в MyWorkingProject, где у меня есть только ссылка на файл CommonUtils.dll - log4net.dll отображается в выходном каталоге (поскольку это зависимость CommonUtils.dll, но не упоминается в MyWorkingProject). Однако, если я создаю новый проект для добавления некоторых модульных тестов: MyWorkingProjectTest и ссылку на проект MyWorkingProject, а затем снова ссылку на файл CommonUtils.dll (я хочу использовать некоторые из CommonUtils), а затем при создании log4net.dll, который является зависимостью в обоих проектах ссылка и ссылка на файл также не копируются в выходной каталог.
Кто-нибудь может прояснить, что здесь происходит? Компилятор не знает, какой из файлов log4net.dll ему следует захватить? Что-то я здесь делаю не так? Должен ли я сделать это каким-либо другим способом, чтобы файл log4net.dll копировался явно? Есть ли смысл в том, что я должен явно ссылаться на log4net?
Ответы 3
Я считаю, что если вы не добавите log4net в качестве ссылки в свой проект, он не будет скопирован.
Я имел в виду не «Ссылку на проект», а скорее «Ссылку» в вашем проекте.
Когда у меня была подобная ситуация в прошлом, я получал предупреждение компилятора в Visual Studio о том, что мне нужно добавить ссылку на зависимую библиотеку.
Получаете ли вы такое предупреждение при компиляции? Если это так, следуйте его советам, и вы обнаружите, что Log4net скопирован в ваш выходной каталог.
Проблема в том, что у меня есть две ссылки, которые имеют зависимости от log4net, и кажется, что в Visual Studio есть встроенная вещь, чтобы не копировать конфликтующую зависимость (несмотря на то, что это одна и та же). Все работает, как ожидалось, если я ссылаюсь только на 1, но не копирую, если я ссылаюсь на оба. ?
Действительно ли обе ссылки относятся к одной и той же сборке? Проверьте свойства каждой ссылки, чтобы убедиться, что путь идентичен.
Это сделано намеренно. Вам нужно подумать о последствиях, которые может вызвать автоматическое наследование ссылок. Хотя вы можете логически увидеть, какими должны быть ссылки, такого разграничения для компилятора нет. Теоретически вы могли бы в конечном итоге воспроизвести Framework и значительную часть вашей ОС, если бы он прошел по всему дереву зависимостей.
Это определенно неприятно, и я согласен с вами и понимаю ваше разочарование, но я предполагаю, что Microsoft не смогла найти логический способ сделать это иначе.
Не могли бы вы посоветовать, как мне тогда это сделать? Если у меня есть LibA и LibB, которые оба зависят от log4net и находятся в MyProjDir / LibA и MyProjDir / LibB, оба содержат log4net.dll. На какой файл log4net.dll следует сослаться? Является ли copy-local true для log4net.dll не лучшим вариантом при сборке libA и libB?
Я лично добавляю любые общие ссылки на проект верхнего уровня. Например, если обе ваши библиотеки будут использоваться приложением, я бы добавил log4net.dll непосредственно в папку / bin приложения. Это не лучшее решение, но я считаю, что это проще, чем искать ссылку.
"by and application" = "by an application". Кроме того, вводить в заблуждение, говоря, что я добавляю ссылки на верхний уровень. Я не добавляю ссылку - я просто добавляю в папку / bin, поскольку она будет в пути поиска библиотек, которые ее ищут.
Хорошо, я понимаю, что я мог бы добавить своего рода задачу пост-сборки, чтобы явно скопировать ее, вместо того, чтобы создавать мои CommonUtils со ссылкой log4net, установленной для копирования local = false?
Как бы вы добавили log4net в качестве ссылки на проект, поскольку у меня есть только распределенная двоичная dll. Также зачем мне добавлять ссылку на нее, поскольку это просто зависимость одной из моих ссылок. Кто-то заявил, что вам не следует ссылаться на библиотеки, которые вы явно не используете в своем коде.