Почему нативная DLL не копируется в выходной каталог

Question

У меня есть проект C # A, который использует DLL-оболочку .net и собственную DLL. Я добавляю DLL-оболочку .net в список ссылок проекта А. Так как DLL-оболочка работает только с собственной DLL-библиотекой, когда они находятся в одной и той же папке, необходимо скопировать собственную DLL-библиотеку в выходной каталог проекта A. Я достиг этого добавив собственную DLL в качестве файла содержимого в проекте A и установите его действие копирования, чтобы копировать, если новее. Это хорошо.

Если проект C # B имеет прямую ссылку на проект A, VS скопирует все зависимые файлы, используемые проектом A, в выходной каталог проекта B. Это означает, что DLL-оболочка и собственная DLL будут скопированы в выходной каталог проекта B также. Это тоже хорошо работает.

Затем у меня есть еще один проект C на C #, который напрямую относится только к проекту B, а не к проекту A. Интересно видеть, что VS не будет копировать нативную DLL в выходной каталог проекта C, что я и намерен чтобы сделать иначе, когда проект C использует функциональность проекта B и ищет собственную DLL для работы с DLL-оболочкой, он не найдет ее.

Может кто-нибудь объяснить, почему VS не копирует нативную DLL в выходной каталог проекта C? Каков механизм копирования цепочечных файлов в VS? Большое спасибо.

Answer 1

В основном ссылочные цепочки не распространяются, и до самой верхней сборки (exe, веб-сайта и т. Д.) Можно убедиться, что в ней есть все, что нужно, локально или внутри (например, с управляемыми dll) GAC. Вам нужно будет добавить файлы на exe / web-сайт как «copy to output».

Answer 2

Поскольку в проекте нет явной зависимости, сборщик не знает, что ее нужно выводить с известными двоичными файлами. Что вы можете сделать, это создать конфигурацию после сборки, чтобы скопировать эти библиотеки DLL в место назначения сборки после компиляции. Вы можете Google, как это сделать , вот один из первых результатов, который объясняет, как это сделать:

http://visualstudiohacks.com/articles/general/customize-your-project-build-process/

Answer 3

Почему бы просто не добавить родную dll в качестве ссылки в проект A? Это гарантирует, что он всегда будет включен, когда другие библиотеки используют A.

Edit: Nevermind, это работает, только если DLL является компонентом COM или .NET.