Как Visual Studio определяет, что копировать в выходной каталог с помощью мультипроектных решений?

Question

Допустим, у нас есть решение со следующей структурой:

• Project.DAL - слой доступа к данным, зависит от библиотеки более низкого уровня, например Oracle.DataAccess с локальной копией = правда
• Project.BLL - слой бизнес-логики, ссылается на Project.DAL как проект
• Project.UI - слой пользовательского интерфейса, компилируется в исполняемый файл, ссылки Project.BLL, проект по умолчанию

Когда Project.UI скомпилирован, VS достаточно умен, чтобы скопировать Project.DAL.dll в выходной каталог, но недостаточно умен, чтобы понять, что я хотел, чтобы Oracle.DataAccess также был скопирован в выходной каталог для раздача клиентам.

Кто-нибудь может объяснить, почему это так? Это потому, что он видит Oracle.DataAccess в GAC и предполагает, что клиенты будут иметь его и в GAC?

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

Answer 1

Еще одна вещь.

Когда вы вообще не используете ссылочную DLL в своем коде , она игнорирует CopyLocal и не скопирует в выходной каталог.

Answer 2

Да, Visual Studio скопирует DLL в выходной путь в любом из следующих двух условий:

1. На DLL явно ссылаются с помощью CopyLocal = true
2. На DLL ссылаются без CopyLocal или неявно через какую-либо другую ссылочную DLL , и ее нет в GAC

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

Я предлагаю вам создать каталог библиотеки, куда вы помещаете все внешние сборки, на которые есть ссылки. Затем вы настраиваете автоматический сценарий MSBuild на компьютере (или виртуальной машине), у которого нет gac'-файла Oracle (и для этого не установлена ​​Visual Studio). Таким образом, файл будет скопирован в сборку, и вы получите больший контроль над тем, что делается, чем при использовании VS.

Answer 3

У меня была странная ситуация, когда, несмотря на то, что сборка была ссылкой на проект и на нее ссылалось «Копировать локальный», отображаемый как «True» в окне свойств ссылки, DLL не копировалась в выходной каталог. У меня была более ранняя версия DLL в GAC, но я не понял, почему это должно предотвратить копирование DLL.

Я обнаружил, что, выгружая проект и вручную редактируя XML-код проекта, выполните следующие действия:

<ProjectReference Include="..\SomeProject.csproj">
  <Project>{11111111-1111-1111-1111-111111111111}</Project>
  <Name>Some Project Name</Name>
  <Private>True</Private>
</ProjectReference>

DLL была скопирована в выходной каталог, как и ожидалось. Я обнаружил, что просто установка Copy Local на True в окне свойств означала, что элемент <Private> полностью отсутствовал, но в случае установки на false он присутствовал со значением «False».

Answer 4

@ RenniePet Вот ссылка на блог, в котором описывается метод RenniePet, описанный в комментарии выше (если вы не хотите редактировать файл проекта вручную, как предложено @Shaun):

http://blogs.msdn.com/b/jjameson/archive/2009/11/18/the-copy-local-bug-in-visual-studio.aspx