it-swarm.com.ru

System.Data.SQLite от NuGet, dll взаимодействия не скопирован в выходной каталог

Я установил System.Data.SQLite Core (x86/x64) из NuGet . Он построен без предупреждений, но выбросил System.DllNotFoundException относительно SQLite.Interop.dll. Я установил свои проекты, чтобы скопировать SQLite.Interop.dll из каталога пакета NuGet в выходной каталог, и теперь он работает без исключения.

Почему пакет NuGet не сконфигурировал мои проекты для помещения соответствующей dll взаимодействия в выходной каталог? Кажется, это должно быть в состоянии сделать это.

Я новичок в взаимодействии, и я унаследовал эту кодовую базу, которая ранее ссылалась на System.Data.SQLite.dll непосредственно по пути. Я переключился на NuGet, чтобы избавиться от предупреждений о несоответствии между процессорной архитектурой проекта и System.Data.SQLite. Я пытаюсь построить все проекты как AnyCPU.

16
Vimes

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

Если вы запустите msbuild in debug для проекта, вы можете найти ссылки на цель CopySQLiteInteropFiles, чтобы убедиться, что она работает.

5
Richard

Скопируйте это в файл вашего проекта:

 <PropertyGroup> 
    <ContentSQLiteInteropFiles>true</ContentSQLiteInteropFiles>
    <CopySQLiteInteropFiles>false</CopySQLiteInteropFiles>
    <CleanSQLiteInteropFiles>false</CleanSQLiteInteropFiles>
    <CollectSQLiteInteropFiles>false</CollectSQLiteInteropFiles>
 </PropertyGroup>

Источник: Файлы SQLite.Interop.dll не копируются в выходной путь проекта, когда это требуется для указанного проекта

8
Stefan

В моем случае проблема заключалась в том, что я использовал SQLite внутри проекта библиотеки классов, который затем использовался другим проектом WPF (тип GUI).

Решил, что SQL.Interop.dll не копируется в выходной каталог, с помощью следующей команды Post-Build в Свойства проекта -> События сборки:

xcopy "$(SolutionDir)packages\System.Data.SQLite.Core.1.0.101.0\build\net451\x86\SQLite.Interop.dll" "$(OutputDir)" /y /f

/y overwrites
/f displays actual filenames being copied
6
Eternal21

С пакетом System.Data.SQLite.Core NuGet версии 1.0.104 у меня была та же проблема, что и у @ Eternal21 и @Patrick. То есть проект A ссылается на SQLite, а проект B ссылается на A, где SQlite.Interop.dll не копируется в выходной каталог B.

Я нашел решение, которое решает проблему в проекте A, а не B, и это более надежное решение, поскольку оно устраняет проблему один раз для всех будущих проектов, ссылающихся на A. Файл .targets пакета NuGet содержит следующий раздел:

<ItemGroup Condition="'$(ContentSQLiteInteropFiles)' != '' And
                      '$(ContentSQLiteInteropFiles)' != 'false' And
                      '@(SQLiteInteropFiles)' != ''">
  <Content Include="@(SQLiteInteropFiles)">
    <Link>%(RecursiveDir)%(FileName)%(Extension)</Link>
    <CopyToOutputDirectory>Always</CopyToOutputDirectory>
  </Content>
</ItemGroup>

В этом разделе добавляется SQLite.Interop.dll в качестве ссылки, которую необходимо скопировать в выходные данные проекта A, а также в выходные данные проектов реферирования (например, B). Но свойство MSBuild ContentSQLiteInteropFiles по умолчанию не определено (я не знаю почему), отключив ссылку по первому условию. Чтобы включить его, я добавил следующую строку в элемент PropertyGroup файла .csproj проектов A:

<ContentSQLiteInteropFiles>true</ContentSQLiteInteropFiles>

Обратите внимание, что эта строка должна предшествовать элементу Import для файла .targets пакета NuGet.

4
florenz

В моем случае SQL.Interop.dll не был скопирован Nuget каким-либо образом, вручную поместил нужную версию DLL в папку x86 и x64.

Если вы установили Sqlite из Nuget, вы можете найти файл SQL.Interop.dll в этой папке (для .NET 4.0).

PROJECT_FOLDER\packages\System.Data.SQLite.Core.1.0.*.*\build\net40

4
Alessio

В моем случае файл myProject.csproj не имел определенного System.Data.SQLite.Core.targets. Я добавил следующую строку, и x64 и x86 версии SQLite.Interop.dll теперь копируются для всех целей сборки.

<Import Project="..\packages\System.Data.SQLite.Core.1.0.98.1\build\net45\System.Data.SQLite.Core.targets" Condition="Exists('..\packages\System.Data.SQLite.Core.1.0.98.1\build\net45\System.Data.SQLite.Core.targets')" />

Я не уверен, что произойдет, когда пакет NuGet для System.Data.SQLite.Core будет обновлен, и если путь к пакету нужно будет изменить вручную.

2
Dave Anderson

в моем случае, используя NuGet для установки SQLite, мне все еще нужно вручную добавить SQliteinterop.dll в качестве ресурса. Затем я создаю мой проект, и когда я публикую его, он работает нормально. (Работа с конфигурацией x86)

0
fedeteka

У меня есть проект DLL, который использует пакет SQLite из nuget, но тестовый проект для него всегда вызывает исключение DLL not found.

Самым простым решением, которое я нашел, было добавление пакета SQLite nuget в тестовый проект.

0
Geoff Johnson

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

Моя конкретная ситуация такая же, как у @ Eternal21 - у меня есть пользовательский интерфейс WPF, использующий клиентскую библиотеку, к которой добавлен SQLite через nuget. И да, проблема заключалась в том, что Interop.dll не был скопирован в загрузочное приложение (т. Е. Пользовательский интерфейс WPF, на котором не установлен SQLite).

Простое добавление SQLite в проект WPF с использованием nuget - это быстрое и простое решение, если вы спешите.

Мое немного сложное решение использует XCOPY, но имеет преимущество в том, что копирует каталоги как x86, так и x64, а также справляется со сборками Debug и Release. Недостатком является то, что он содержит жестко закодированные имена проектов. Я вижу, как можно использовать макрос, чтобы избавиться от первого, но я не мог легко понять, как избавиться от второго, поэтому вам придется изменить его вручную, если имя проекта изменилось (но это довольно редко ).

Мое решение состоит в том, чтобы использовать эти команды XCOPY в пост-сборке запускаемого проекта:

xcopy $(SolutionDir)DALProject\bin\$(ConfigurationName)\x64\SQLite.Interop.dll $(SolutionDir)WPFProject\bin\$(ConfigurationName)\x64\*.* /C /F /S /E /Y
xcopy $(SolutionDir)DALProject\bin\$(ConfigurationName)\x86\SQLite.Interop.dll $(SolutionDir)WPFProject\bin\$(ConfigurationName)\x86\*.* /C /F /S /E /Y

/ C - Продолжает копирование, даже если ошибка (возможно, это не нужно).

/ F - отображает полные пути копируемых файлов (может быть опущен для очистки вывода сборки).

/ S - Копирует подкаталоги (это был единственный способ, которым я мог получить его для создания папок/x86 и/x64).

/ E - Копирует каталоги и подкаталоги (возможно, дубликаты/S).

/ Y - Подавляет запрос, если целевой файл уже существует.

Я установил это, чтобы работать только на успешной сборке, и это работает удовольствие для меня. Надеюсь, это кому-нибудь поможет. 

0
Patrick