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

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

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

ОТВЕТЫ

Ответ 1

В 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, сохранить проект, а затем reset до True - сохранить снова. Это включает в себя Private node правильно, что MSBuild уважает.

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

Ответ 2

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

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

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

Ответ 3

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

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

Ответ 4

Я получал точно такую ​​же проблему. У нас есть проект 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".

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

Ответ 5

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

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

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

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

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

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

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

Ответ 6

Я не уверен, как это было настроено в Visual Studio 2008, но я почти уверен, что вы, возможно, использовали командную строку события Post-Build. Там вы можете скопировать файлы DLL, необходимые для развертывания. Пример приведен ниже:

mkdir $(SolutionDir)\Deployment
copy "$(SolutionDir)Your_Library_Name\Your_Dll_ForDeployement.dll" 
$(SolutionDir)\Deployment\

Ответ 7

Я не встречал ту же проблему, но схожую. У меня был основной проект WPF и ссылка на проект, в котором ссылка не копировалась. Я обнаружил, что в моем случае основной проект был настроен для профиля клиента NET 4.0 и ссылки для NET 3.5. Когда я устанавливаю основной проект на 3.5, скомпилированная dll ссылочного проекта начала копировать. (Я не знаю, почему, потому что я решил это на практике)

Ответ 8

Мы можем использовать <Private>False</Private>, чтобы не копировать связанные файлы DLL в каталог bin. Это полезно, когда мы создаем приложения на отдельном сервере сборки TFS, где нам нужно создать приложение, а не копировать файлы DLL в каталог bin.

Ответ 9

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

Ответ 10

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

Ответ 11

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

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

Ответ 12

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

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

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

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

JH

Ответ 13

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

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