Ссылочный DLL-файл не копируется в корзину с проектом развертывания, вызвавшим ошибку - PullRequest
Новая
       46

Ссылочный DLL-файл не копируется в корзину с проектом развертывания, вызвавшим ошибку

58 голосов
/ 01 июня 2010

У нас есть несколько внешних DLL-файлов, на которые есть ссылки в нашем проекте веб-приложения.У нас есть проект развертывания для установки на серверы хостинга.Когда мы использовали .NET 3.5 и Visual Studio 2008, DLL-файл копировался в папку bin.Поскольку мы обновились до .NET 4 и Visual Studio 2010, этого больше не происходит, и мы получаем ошибки серверов, поскольку ссылки не могут быть найдены.

Для CopyLocal установлено значение true, и я не могу найти что-либо в Интернете.config, который предполагает, что это устанавливается в другом месте.

Ответы [ 13 ]

102 голосов
/ 21 ноября 2011

В Visual Studio 2010 есть ошибка. По умолчанию XML в файле решения выглядит следующим образом: 

<Reference Include="DevExpress.SpellChecker.v11.1.Core,
           Version=11.1.5.0,
           Culture=neutral,
           PublicKeyToken=b88d1754d700e49a,
           processorArchitecture=MSIL">
<HintPath>..\References\DevExpress.SpellChecker.v11.1.Core.dll</HintPath>
</Reference>

Принимая во внимание, что MSBuild ожидает этого ниже, так что файл DLL будет включен в развертывание: 

<Reference Include="DevExpress.SpellChecker.v11.1.Core,
           Version=11.1.5.0,
           Culture=neutral,
           PublicKeyToken=b88d1754d700e49a,
           processorArchitecture=MSIL">
<HintPath>..\References\DevExpress.SpellChecker.v11.1.Core.dll</HintPath>
<Private>True</Private>
</Reference>

Хитрость в том, чтобы установить Copy Local на False, сохранить проект , а затем сбросить его на True - сохранить еще раз . Это включает в себя частный узел правильно, что MSBuild уважает.

Похоже, что по умолчанию для не включенного частного узла (Copy Local) в Visual Studio 2010 установлено значение True, а MSBuild считывает этот отсутствующий узел как False.

3 голосов
/ 29 декабря 2011

У меня возникла та же проблема, и вместо того, чтобы добавить шаг "BeforeBuild", я создал тест, который просто сделал это 

    [TestMethod]
    public void ReferenceAssemblyThatDoesNotCopyToBuildFolder()
    {
        Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.Logging.LoggingExceptionHandler referenceThisButDoNotUseIt = null;
    }

И это исправило ошибку. Тип 'Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.Logging.LoggingExceptionHandler ...' не может быть разрешен

2 голосов
/ 01 июня 2010

Что-то странное случилось с моим проектом развертывания. Когда я увидел, что у него нет обнаруженных зависимостей, я удалил основной вывод и снова добавил его.

Зависимости теперь отображаются и помещаются в папку bin после установки.

1 голос
/ 31 мая 2015

У меня была та же проблема, и я хотел поделиться тем, что нашел, так как это может кому-то помочь:

Причиной в моем случае было то, что сборка была установлена ​​в GAC во время установки какого-либо стороннего приложения.

Если файл DLL находится в GAC, компилятор не потрудится скопировать его в папку назначения, если только вы специально не отметите его как «copy local» с помощью узла «Private» в файле проекта, как упомянуто Junto .

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

Большая проблема заключается в том, что на файл DLL нет прямой ссылки, но проект ссылается на второй проект, который, в свою очередь, ссылается на файл DLL. В этом случае вы не можете пометить файл DLL как «локально скопированный» в проекте, так как он на него не ссылается. Поэтому, если файл DLL существует в GAC - он не будет скопирован в вашу выходную папку.

Возможные решения в этом случае:

  • Удалите файл DLL из GAC
  • Добавить прямую ссылку на файл DLL в конечный проект (ы)
  • Повторно подписать файл DLL новым строгим именем, которое будет отличать его от файла DLL в GAC.
1 голос
/ 06 августа 2010

У меня точно такая же проблема. У нас есть проект Visual Studio 2008, который ссылается на EnterpriseLibrary. Когда мы запускаем нашу интегрированную сборку с использованием TFS и нашего проекта веб-развертывания, все файлы DLL копируются. При обновлении до Visual Studio 2010, TFS 2010 и WDP 2010 некоторые файлы DLL отсутствовали. Как ни странно, это происходит только с некоторыми DLL-файлами, а не с другими.

Например, в обоих случаях мы получаем копию Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.dll, но не Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.Logging.dll.

В качестве обходного пути я скопировал файлы, используя шаг «BeforeBuild».

Теперь кажется, что все в порядке.

0 голосов
/ 14 октября 2016

Если ваш проект не загружает библиотеку напрямую, она не всегда будет развернута, даже если на нее явно ссылаются! Я запутался, потому что мог видеть его в локальном каталоге Bin, но не при развертывании. DLL в каталоге Bin был старым файлом, который не был удален во время очистки, поэтому я запутался.

Полная очистка и восстановление, и это не было в моей локальной папке Bin, что показало мне проблему (я использую его только в web.config). Затем я сослался на сам файл dll в проекте и установил его для копирования в выходной файл, чтобы убедиться, что он развернут.

0 голосов
/ 29 апреля 2016

rzen и другие, спасибо - ваши комментарии привели к решению для нас.

У нас есть проект, предназначенный для версии 10 сборок Microsoft.ReportViewer.Common.dll и Microsoft.ReportViewer.WebForms.dll (отдельная папка «libs», созданная нами на уровне «src»). Но когда мы делали сборку, вывод включал версию 12, которая была недавно установлена ​​на сервере сборки.

Используя комментарии, мы убедились, что для параметра «Копировать локально» задано значение «Истина» и установлен флаг в файле проекта. Тем не менее, он все еще развертывал версию 12. Так что мы нашли, что сделали хитрость, было то, что свойство «Конкретная версия» также было установлено в двух ссылках. Вуаля, версия 10 каждого файла сейчас разворачивается!

Было много радости.

JH

0 голосов
/ 05 февраля 2016

У меня была похожая проблема с VS 2012 Express. Я использовал библиотеки Tesseract в своем проекте. Все работало хорошо, пока я не использовал этот проект в решении, где было более одного проекта. Проблема заключалась в том, что некоторые библиотеки DLL (liblept168.dll, libtesseract302.dll), которые обычно помещаются в папки bin / debug / x86 или bin / debug / x64, копировались только при перестроении всего решения. Изменение одной строки и ее построение привело к тому, что библиотеки DLL были удалены и не скопированы обратно.

Я решил эту проблему, добавив ссылку на проект, который создает недостающие библиотеки DLL, в стартовый проект.

0 голосов
/ 06 мая 2015

Я тоже столкнулся с подобной проблемой, когда указанные библиотеки не были скопированы в корзину в опубликованной папке. Я использовал извлеченную копию TFS, которая не включала папку bin в приложение. -> Так что просто включил папку bin. -> Встроенные ссылочные приложения -> Опубликован сайт проекта Теперь я вижу все упомянутые dll в bin в опубликованной папке

0 голосов
/ 28 августа 2014

Проверьте рамки проекта, в котором был указан файл DLL. Фреймворк должен быть .NET 4.0. Пожалуйста, исправьте это, если фреймворк является Client Profile.

Страница:
...