Периодически я получаю следующее исключение:

Unable to load DLL 'SQLite.Interop.dll': The specified module could not be found. (Exception from HRESULT: 0x8007007E)

Я использую 1.0.82.0. версия, установив ее с помощью nuget в VS2010, ОС Win7 64.

Как только исключение начинает появляться, оно появляется постоянно - при отладке, выпуске и запуске приложения внутри или вне VS.

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

Кто-нибудь видел что-то подобное и есть ли решение для этого?

Я знаю, что опоздал на вечеринку, но у меня возникла эта проблема сразу после того, как я сегодня снял последнюю версию x86 / x64 (версия 1.0.88.0). Мой локальный IIS в VS2012 работает по умолчанию с 32-битной версией, и нет простого способа перейти на x64. Мой рабочий сервер работает на 64-битной.

В любом случае я установил пакет NuGet в проект DLL и получил эту ошибку. Что я должен был сделать, чтобы это работало, я должен был установить это на главный сайт проект . Даже если это не касается классов SQLite.

Я предполагаю, что SQLite использует сборку ввода, чтобы определить, какую версию Interop загрузить.

У меня была эта проблема, потому что у dll, которую я использовал, была Sqlite как зависимость (настроенная в NuGet только с базовым пакетом Sqlite.). Проект компилирует и копирует все Sqlite dll-ы, кроме «SQLite.Interop.dll» (как папки x86, так и x64).

Решение было очень простым: просто добавьте пакет Sqlite.Core в качестве зависимости (с NuGet) в проект, который вы создаете / выполняете, и dll-ы будут скопированы.

У меня была такая же проблема при использовании SQLite в проекте WPF, целью которого была платформа Any CPU. Я исправил это, выполнив следующие шаги:

1. Откройте дизайнер проекта в Visual Studio. Подробности о том, как это сделать, можно найти здесь .
2. Нажмите на вкладку Build.
3. Отключить prefer 32-bitопцию.

В качестве альтернативы, вы можете просто установить цель платформы на x86или x64. Я думаю, что эта проблема вызванаSystem.Data.SQLite библиотека использует целевой объект платформы для определения местоположения файла «SQLite.Interop.dll».

ОБНОВИТЬ:

Если конструктор проекта не может быть достигнут, просто откройте *.csprojфайл project ( ) из текстового редактора и добавьте значение <Prefer32Bit>false</Prefer32Bit>в <PropertyGroup>...</PropertyGroup>тег.

Пример кода

<PropertyGroup>
    <Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
    <Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform>
    <ProjectGuid>[Set by Visual Studio]</ProjectGuid>
    <OutputType>Exe</OutputType>
    <AppDesignerFolder>Properties</AppDesignerFolder>
    <RootNamespace>[Set by Visual Studio]</RootNamespace>
    <AssemblyName>[Set by Visual Studio]</AssemblyName>
    <TargetFrameworkVersion>v4.5</TargetFrameworkVersion>
    <FileAlignment>[Set by Visual Studio]</FileAlignment>
    <!--Add the line below to your project file. Leave everything else untouched-->
    <Prefer32Bit>false</Prefer32Bit>
</PropertyGroup>

Вот как я это исправил в своем проекте.

Это работало, и когда коллега представил свои изменения, я получил исключение «Невозможно загрузить DLL« SQLite.Interop.dll »».

В отличие от файла .csproj проекта, это было в НЕ РАБОЧЕЙ версии:

<ItemGroup>
     <Content Include="x64\SQLite.Interop.dll" />
     <Content Include="x86\SQLite.Interop.dll" />
</ItemGroup>

И вот что было в РАБОЧЕЙ версии:

<ItemGroup>
     <Content Include="x64\SQLite.Interop.dll">
          <CopyToOutputDirectory>Always</CopyToOutputDirectory>
      </Content>
      <Content Include="x86\SQLite.Interop.dll">
          <CopyToOutputDirectory>Always</CopyToOutputDirectory>
      </Content>
</ItemGroup>

Вернувшись назад, я не получил исключение. Файлы DLL были выгружены в соответствующие папки Debug \ x64 (и т. Д.).

Таким образом, после добавления NuGet развертывание не копирует Interops. Вы можете добавить это в свой файл csproj, и это должно исправить это поведение:

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

Если вы посмотрите исходный код NuGet для SQLite, вы увидите, что именно они делают. Это позволило мне развернуть работу с ASP.Net Core.

Когда вы попадете в это состояние, попробуйте выполнить Rebuild-All. Если это решит проблему, у вас может быть та же проблема, что и у меня.

Немного предыстории (мое понимание) :

• SQLite имеет 1 управляемую сборку (System.Data.SQLite.dll) и несколько сборок, специфичных для платформы (SQLite.Interop.dll). При установке SQLite с Nuget, Nuget добавит специфичные для платформы сборки в ваш проект (в нескольких папках: \ x86, \ x64) и сконфигурирует эти библиотеки как «Копировать всегда».

• При загрузке управляемая сборка будет искать специфичные для платформы сборки в папках \ x86 и \ x64. Вы можете увидеть больше об этом здесь . Исключением является то, что эта управляемая сборка пытается найти соответствующие (SQLite.Interop.dll) внутри этих папок (и не удается).

Мой сценарий :

У меня есть 2 проекта в моем решении; приложение WPF и библиотека классов. Приложение WPF ссылается на библиотеку классов, а библиотека классов ссылается на SQLite (устанавливается через Nuget).

Для меня проблема заключалась в том, что, когда я изменяю только приложение WPF, VS пытается выполнить частичное восстановление (понимая, что зависимая DLL не изменилась). Где-то в этом процессе VS очищает содержимое папок \ x86 и \ x64 (удаляя SQLite.Interop.dll). Когда я делаю полную Rebuild-All, VS копирует папки и их содержимое правильно.

Мое решение :

Чтобы это исправить, я добавил процесс пост-сборки с использованием xcopy, чтобы принудительно скопировать папки \ x86 и \ x64 из библиотеки классов в мой каталог \ bin проекта WPF.

В качестве альтернативы, вы можете сделать более интересные вещи с помощью конфигурационных / выходных каталогов сборки.

У меня была та же проблема с Visual Studio Express 2013. Я пробовал несколько решений, упомянутых здесь и в других местах, но безрезультатно. Я надеюсь, что это исправление помогает другим.

Я исправил это с помощью DeploymentItemатрибута в моем тестовом классе, который тестирует службу на основе SQLite.

Пример:

[TestClass]
[DeploymentItem(@"x86\SQLite.Interop.dll", "x86")] // this is the key
public class LocalStoreServiceTests
{

    [TestMethod]
    public void SomeTestThatWasFailing_DueToThisVeryIssue()
    {
         // ... test code here
    }
}

Это приводит к необходимости SQLite.Interop.dllскопировать вx86 каталог в соответствующей папке «TestResults».

Все зелено. Все хорошо.

Обновление NuGet Tools -> Extension and updatesи переустановка SQLite.Core с помощью команды PM> Update-Package -reinstall System.Data.SQLite.Coreисправило это для меня.

У меня была похожая проблема в решении нескольких проектов. SQLite.Interop.dll был необходим для одного из плагинов, распространяемых вместе с программным обеспечением, использующим ClickOnce.

Что касается отладки в visual studio, то все работало нормально, но в развернутой версии отсутствовали папки x86 / и x64 /, содержащие эту DLL.

Чтобы заставить его работать после развертывания с использованием ClickOnce, нужно было создать в стартовом проекте решения (также опубликованного) эти две подпапки, скопировать в них библиотеки DLL и установить их как Content Copy Always.

Таким образом, инструмент публикации ClickOnce автоматически включает эти файлы и папки в манифест и развертывает программное обеспечение вместе с ними.

Здесь действительно много ответов, но у меня все просто и понятно с отсутствием GAC-игры .

Проблема заключалась в том, что SQLite.Interop.dllдля доступа к нашей базе данных исполняемому файлу требуется копия права (x86 или x64).

В основном у архитектур есть слои, а в моем случае уровень данных имеет необходимую DLL для подключения SQLite.

Поэтому я просто вставил скрипт посткомпоновки в решение Data Layer, и все заработало нормально.

TL; DR;

1. Установите для всех проектов вашего решения x86или x64в опциях сборки.

2. Добавить следующее Post-Build-Scriptк проекту с SQLite nuget Package:

   xcopy "$(TargetDir)x64" "$(SolutionDir)bin\Debug\" /y

Конечно, вы должны изменить сценарий для Release Buildи x86сборок.

STL; DR;

Поместите SQLite.Interop.dllрядом с *.exeфайлом.

Установка по умолчанию SQLite-версии с несколькими архитектурами (x86, x64) от NuGet демонстрирует поведение, которое вы описали. Если вы хотите загрузить правильную версию для фактической архитектуры, которую среда выполнения .NET выбрала для запуска приложения на вашем компьютере, то вы можете дать загрузчику DLL подсказку о том, где найти правильную библиотеку, следующим образом:

Добавьте объявление для вызова функции kernel32.dll в SetDLLDirectory () перед вашей Program.Main ():

    [System.Runtime.InteropServices.DllImport("kernel32.dll", CharSet = System.Runtime.InteropServices.CharSet.Unicode, SetLastError = true)]
    [return: System.Runtime.InteropServices.MarshalAs(System.Runtime.InteropServices.UnmanagedType.Bool)]
    static extern bool SetDllDirectory(string lpPathName);

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

    [STAThread]
    static void Main()
    {
        int wsize = IntPtr.Size;
        string libdir = (wsize == 4)?"x86":"x64";
        string appPath = System.IO.Path.GetDirectoryName(Application.ExecutablePath);
        SetDllDirectory(System.IO.Path.Combine(appPath, libdir));

даже если это старый пост, я хотел бы поделиться решением, которое я нашел здесь: http://system.data.sqlite.org/index.html/info/54e52d4c6f

Если вы не хотите читать все проблемы, решение состоит в том, чтобы скопировать файл "msvcr100.dll" (который находится в каталоге Windows \ System32) по тому же пути, что и SQLite.Interop.dll.

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

HTH, Форментц

Как говорится в вики SQLite , ваше приложение должно быть:

Так что нужно соблюдать правила. Найдите dll, которая соответствует вашей целевой платформе, и поместите ее в нужное место, описанное на картинке. Dlls можно найти в YourSolution / packages / System.Data.SQLite.Core.% Version% /.

У меня были проблемы с развертыванием приложения, поэтому я просто добавил в свой проект правильный файл SQLite.Interop.dll, добавил папку x86 в AppplicationFolder в проекте установки и добавил ссылки на файлы в dll.

Вы также можете получить эту ошибку, если вы пытаетесь запустить 32-битную DLL в 64-битном проекте.

Я получил это, когда поместил один и тот же файл (SQLite.Interop.dll в 32-разрядной версии) в папку x86 и x64.

Если вы загрузили правильный двоичный файл для, SQLiteскопируйте его SQLite.Interop.dllв папку Release или Debug в соответствии с опцией сборки вашего проекта.

Я не знаю, почему это еще не было включено, но я должен был провести исследование и выяснить это для себя, так что, надеюсь, кто-то найдет этот ответ и спасет проблему. Это было для приложения WPF. Он отлично работал на моем устройстве Dev, но не работал на компьютере, где я его копировал, и получил Unable to load DLL 'SQLite.Interop.dll'ошибку. Я перенес все связанные с ним каталоги и файлы прямо из папки «Debug» на этот другой компьютер, когда у меня возникла та же ошибка, что и у OP при запуске. Моя папка «bin», в которой находились мои библиотеки DLL, была скопирована в «Debug \ bin», и все они были включены вместе с файлами приложения, когда я выполняла копирование на другой компьютер по этому пути, поэтому в ней не было пропущено ни одного файла.

То, что я видел, говорилось в других ответах, которые не были применимы:

• Я не использовал пакет NuGet и не нуждался в создании папок x86 или x64, которые, кажется, создает пакет NuGet. Мои библиотеки DLL (System.Data.SQLite и SQLite.Interop.dll вместе с System.Data.SQLite.config) находятся в папке «bin» в моем проекте и были скопированы вручную (создайте папку «bin» в обозревателе решений в VS, вставьте библиотеки DLL в эту папку в проводнике Windows, используйте Добавить> Существующий элемент для переноса файлов в папку / проект VS). Затем я ссылаюсь на них как на «Связанные сборки» в моем проекте, используя это местоположение («Ссылки»> «Добавить ссылку», и просматриваю одну, промываю, повторяю для остальных). Это гарантирует, что мой проект точно знает, где они находятся.
• Мне не нужно было ссылаться на какой-либо файл DLL SQLite в моем app.config или даже касаться моего файла MyProject.csproj.
• Мне даже не нужно было указывать конкретный процессор! Мой проект предназначен для «Любого процессора», хотя у меня есть только смешанные или 64-битные библиотеки DLL, и я буду работать только в Windows 7+, которые являются 64-битными ОС. (нет только x86 / только 32-битных DLL)
• Я уже определял их как «Содержимое» и «Копировать, если новее» для этих библиотек DLL, когда обнаружил ошибку OP.

Я обнаружил следующее : https://system.data.sqlite.org/index.html/doc/trunk/www/faq.wiki#q20 :

(11) Почему я получаю DllNotFoundException (для "sqlite3.dll" или "SQLite.Interop.dll") при попытке запустить мое приложение?

Либо указанная библиотека динамических ссылок (DLL) не может быть найдена, либо ее невозможно загрузить из-за отсутствующих зависимостей. Убедитесь, что именованная динамическая библиотека находится в каталоге приложения или в каталоге по системной переменной PATH, и повторите попытку. Кроме того, убедитесь, что установлен необходимый распространяемый файл среды выполнения Visual C ++. если только вы не используете динамически подключаемую библиотеку, статически связанную с ней.

Акцент мой на этой жирной части внутри абзаца. Целевой компьютер был свежим и не загружал никаких программ, кроме .NET 4.0. После того, как я установил C ++, он смог выполнить команды для SQLite. Это должно было быть одним из первых часто задаваемых вопросов и частью предварительных требований, но он был похоронен в # 11. Мой компьютер уже был загружен, потому что он поставлялся с Visual Studio, поэтому он работал там.

Загрузить:
Распространяемый Visual C ++ для Visual Studio 2015:
https://www.microsoft.com/en-us/download/details.aspx?id=48145.

Обновление 3 (накопительное обновление):
https://www.microsoft.com/en-us/download/details.aspx?id=53587

Я начал использовать Costura.Fody для упаковки (.net) сборок, а также встраивания и предварительной загрузки собственных dll. Это также помогает позже, с распространением, так как вы можете отправить один файл.

1. Установите Костура Фоди из Nuget.

2. В вашем проекте C # создайте папку с именем costrua32. Там добавьте любые родные dll, которые вы загружаете на C #.

3. После того, как вы добавили их в эту папку. Нажмите на окно свойств и измените действие сборки на «Встроенный ресурс».

4. Наконец, вам нужно изменить файл XML с именем FodyWeavers.xml следующим образом. Здесь я указываю загрузить SQL DLL сначала. (обратите внимание, что вы бросаете .dll)

   Weavers
    Costura
     PreloadOrder
      SQLite.Interop
      tbb_debug
      tbb
     /PreloadOrder>
    /Costura
   /Weavers

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

Также добавил dll в тестовый проект (через Nuget Manager) и исправил его.

У меня была эта проблема, потому что распространяемый Visual C ++ 2010 не установлен на моем ПК. Если вы еще не установили распространяемый Visual C ++ 2010 Загрузите и установите это (проверьте x86 или 64 dll).

У меня та же проблема. Однако, наконец, я могу это исправить. В настоящее время я использую Visual Studio 2013 Community Edition. Я просто использую Add-> Existing Item ... и просматриваю, где находятся файлы SQLite.Data.SQLite (мой случай 'C: \ Program Files (x86) \ System.Data.SQLite \ 2013 \ bin'). Пожалуйста, не забудьте изменить тип того, что вы будете включать в файлы сборки (* .dll; * .pdb) . Выберите « SQLite.Interop.dll » в этой папке. С этого момента я могу продолжить без каких-либо проблем. Удачи всем вам. ^ _ ^ PS Я создаю приложение веб-формы. Я еще не пробовал в форме окна приложения или других.

Попробуйте установить целевую платформу на x86 или x64 (а не на любой ЦП) перед сборкой: Project-> Properties-> Build-> Platform target в Visual Studio.

Скопируйте SQLite.Interop.dll в каталог проекта.

src\
  project\
      bin\   <-- Past in bin
         x64\
           SQLite.Interop.dll <-- Copy this if 64
         x86\
           SQLite.Interop.dll <-- Copy this if 32

Я долго боролся с этим и иногда обнаруживал, что настройки теста неверны. Смотрите это изображение:

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

Скопируйте файлы «SQLite.Interop.dll» для x86 и x64 в папку отладки. эти файлы должны быть скопированы в папки «x86» и «x64» в папке отладки.

Мое приложение является веб-приложением (ASP.NET MVC), и мне пришлось изменить пул приложений для запуска LocalSystemвместо него ApplicationPoolIdentity. Сделать это:

1. Открыть IIS Manager
2. Найдите пул приложений, под которым работает ваш сайт.
3. Нажмите Расширенные настройки из действий
4. Изменить личность на LocalSystem

Я понятия не имею, почему это решает проблему.

Я не знаю, хороший ли это ответ, но я смог решить эту проблему, запустив свое приложение под доменом приложения с идентификатором «Локальная система».

Я работаю над простым консольным приложением, чтобы добавить некоторые тестовые данные в базу данных SQLite, и получаю эту ошибку. Конфигурация для проекта «Любой процессор». Я исправил это, скопировав SQLite.Interop.dll в папку bin \ debug. Лучше было бы использовать метод @Wil, но как указать это для конфигурации «Любой процессор»?

Может ли быть спор за сборку? Проверьте, есть ли другое приложение с блокировкой файла в DLL.

Если это причина, должно быть легко использовать такой инструмент, как Sysinternal Process Explorer, чтобы обнаружить нарушающую программу.

HTH, глина

Для справки для тех, кто смотрит на этот вопрос:

Если вы используете пакет nuget, он устанавливает правило сборки, которое выполняет копирование за вас. (см. System.Data.SQLite.Core.1.0.94.0 \ build - или любую версию Core, которую вы устанавливаете).

Установщик nuget автоматически добавляет правило в файл проекта.

Это все еще не решает проблему тестового примера, хотя. Подход DeploymentItem ( https://stackoverflow.com/a/24411049/89584 ) - единственное, что, похоже, работает там.

Я столкнулся с этой проблемой в решении с веб-проектом WebAPI / MVC5 и проектом Feature Test, в котором использовался один и тот же проект доступа к данным (или «Core»). Я, как и многие другие здесь, использую копию, загруженную через NuGet в Visual Studio 2013.

То, что я сделал, в Visual Studio добавило папку с решениями для x86 и x64 в Feature Test и веб-проекты. Затем я сделал Right Click | Add Existing Item...и добавил соответствующую библиотеку SQLite.interop.dll ..\SolutionFolder\packages\System.Data.SQLite.Core.1.0.94.0\build\net451\[appropriate architecture]для каждой из этих папок. Затем я сделал Right Click | Properties, и набор Copy to Output Directoryв Always Copy. В следующий раз, когда мне нужно было выполнить свои функциональные тесты, тесты прошли успешно.