Je reçois périodiquement l'exception suivante:

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

J'utilise 1.0.82.0. version, l'installer avec nuget dans VS2010, OS Win7 64.

Une fois que l'exception commence à apparaître, elle apparaît constamment - dans le débogage et la publication et l'application en cours d'exécution à l'intérieur ou à l'extérieur de VS.

La seule façon de l'arrêter est la déconnexion et la connexion. L'exception n'est pas levée et la DLL est chargée. Cela peut fonctionner pendant des jours, mais il peut à nouveau se casser.

Quelqu'un a-t-il vu quelque chose comme ça et y a-t-il une solution?

Je sais que je suis en retard à la fête, mais j'ai eu ce problème juste après avoir sorti le dernier x86 / x64 aujourd'hui (version 1.0.88.0). Mon IIS local dans VS2012 fonctionne en 32 bits par défaut et il n'y a pas de moyen facile de passer en x64. Mon serveur de production fonctionne en 64 bits.

Quoi qu'il en soit, j'ai installé le package NuGet dans un projet DLL et j'ai eu cette erreur. Ce que je devais faire pour le faire fonctionner, je devais également l' installer sur le projet du site principal . Même s'il ne touche pas du tout aux classes SQLite.

Je suppose que SQLite utilise l'assembly d'entrée pour détecter la version d'Interop à charger.

J'ai eu ce problème car une DLL que j'utilisais avait Sqlite comme dépendance (configurée dans NuGet avec uniquement le package de base Sqlite.). Le projet compile et copie toutes les dll-s Sqlite à l'exception du 'SQLite.Interop.dll' (dossier x86 et x64).

La solution était très simple: ajoutez simplement le package Sqlite.Core en tant que dépendance (avec NuGet) au projet que vous construisez / exécutez et les dll-s seront copiés.

J'ai eu ce même problème lors de l'utilisation de SQLite dans un projet WPF dont la plate-forme cible était Any CPU. Je l'ai corrigé en suivant les étapes suivantes:

1. Ouvrez le concepteur de projet dans Visual Studio. Les détails sur la façon de le faire peuvent être trouvés ici .
2. Cliquez sur l'onglet Build.
3. Désactivez l' prefer 32-bitoption.

Alternativement, vous pouvez simplement définir la cible de la plate-forme sur x86ou x64. Je pense que ce problème est dû au fait que la System.Data.SQLitebibliothèque utilise la cible de la plate-forme pour obtenir l'emplacement du fichier 'SQLite.Interop.dll'.

METTRE À JOUR:

Dans le cas où le concepteur de projet ne peut pas être atteint, ouvrez simplement le *.csprojfichier project ( ) à partir d'un éditeur de texte et ajoutez la valeur <Prefer32Bit>false</Prefer32Bit>dans la <PropertyGroup>...</PropertyGroup>balise.

Exemple de code

<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>

C'est ainsi que je l'ai corrigé dans mon projet.

Cela fonctionnait et lorsqu'un collègue a soumis ses modifications, j'ai reçu l'exception "Impossible de charger la DLL 'SQLite.Interop.dll'".

Différent du fichier .csproj du projet, il était dans la version NON-WORKING:

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

Et voici ce que la version WORKING avait:

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

Après être revenu en arrière, je n'ai pas reçu l'exception. Les fichiers DLL ont été vidés dans les dossiers Debug \ x64 (etc) appropriés.

Ainsi, après avoir ajouté NuGet, le déploiement ne copie pas les Interops. Vous pouvez l'ajouter à votre fichier csproj et cela devrait corriger ce problème:

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

Si vous regardez dans la source de NuGet pour SQLite, vous pouvez voir ce que cela fait spécifiquement. Cela m'a permis d'obtenir un déploiement avec ASP.Net Core.

Lorsque vous obtenez dans cet état, essayez d'effectuer une reconstruction-tout. Si cela résout le problème, vous pouvez avoir le même problème que moi.

Quelques antécédents (ma compréhension) :

• SQLite possède 1 assembly géré (System.Data.SQLite.dll) et plusieurs assemblys spécifiques à la plate-forme (SQLite.Interop.dll). Lors de l'installation de SQLite avec Nuget, Nuget ajoutera les assemblys spécifiques à la plate-forme à votre projet (dans plusieurs dossiers: \ x86, \ x64), et configure ces DLL sur "Copier toujours".

• Lors du chargement, l'assembly géré recherchera des assemblys spécifiques à la plateforme dans les dossiers \ x86 et \ x64. Vous pouvez en voir plus ici . L'exception est cet assembly managé qui tente de trouver le (SQLite.Interop.dll) approprié dans ces dossiers (et échoue).

Mon scénario :

J'ai 2 projets dans ma solution; une application WPF et une bibliothèque de classes. L'application WPF fait référence à la bibliothèque de classes et la bibliothèque de classes fait référence à SQLite (installé via Nuget).

Le problème pour moi était lorsque je modifie uniquement l'application WPF, VS tente de faire une reconstruction partielle (en réalisant que la DLL dépendante n'a pas changé). Quelque part dans ce processus, VS nettoie le contenu des dossiers \ x86 et \ x64 (en supprimant SQLite.Interop.dll). Lorsque je fais une reconstruction complète, VS copie correctement les dossiers et leur contenu.

Ma solution :

Pour résoudre ce problème, j'ai fini par ajouter un processus de post-génération à l'aide de xcopy pour forcer la copie des dossiers \ x86 et \ x64 de la bibliothèque de classes vers mon répertoire de projet WPF \ bin.

Alternativement, vous pouvez faire des choses plus sophistiquées avec les répertoires de configuration / sortie de la construction.

J'ai eu le même problème lors de l'exécution de Visual Studio Express 2013. J'ai essayé plusieurs solutions mentionnées ici et ailleurs en vain. J'espère que cette correction aide les autres.

Je l'ai corrigé en utilisant l' DeploymentItemattribut sur ma classe de test qui teste le service basé sur SQLite.

Exemple:

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

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

Cela provoque la SQLite.Interop.dllcopie nécessaire dans le x86répertoire dans le dossier "TestResults" approprié.

Tout est vert. Tout est bon.

La mise à jour de NuGet Tools -> Extension and updateset la réinstallation de SQLite.Core avec la commande l'ont PM> Update-Package -reinstall System.Data.SQLite.Corecorrigé pour moi.

J'ai eu un problème similaire dans une solution à projets multiples. Le SQLite.Interop.dll était nécessaire pour l'un des plugins distribués avec le logiciel utilisant ClickOnce.

En ce qui concerne le débogage dans Visual Studio, tout fonctionnait bien, mais la version déployée manquait les dossiers x86 / et x64 / contenant cette DLL.

La solution pour le faire fonctionner après le déploiement à l'aide de ClickOnce était de créer dans le projet de démarrage de la solution (également celui en cours de publication) ces deux sous-dossiers, de copier dans eux les DLL et de les définir comme Content Copy Always.

De cette façon, l'outil de publication ClickOnce inclut automatiquement ces fichiers et dossiers dans le manifeste et déploie le logiciel avec eux

Il y a vraiment beaucoup de réponses ici, mais la mienne est simple et claire avec un jeu sans GAC .

Le problème était que le fichier exécutable a besoin d'une copie du droit SQLite.Interop.dll(x86 ou x64) pour accéder à notre base de données.

La plupart des architectures ont des couches et dans mon cas, la couche de données a la DLL requise pour la connexion SQLite.

J'ai donc simplement mis un script de post-construction dans ma solution de couche de données et tout a bien fonctionné.

TL; DR;

1. Définissez tous les projets de votre solution sur x86ou x64dans les options de génération.

2. Ajoutez les éléments suivants Post-Build-Scriptau projet avec SQLite nuget Package:

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

Bien sûr, vous devez changer le script Release Buildet les x86builds.

STL; DR;

Mettez votre à SQLite.Interop.dllcôté du *.exefichier.

L'installation par défaut de la version multi-architecture (x86, x64) de SQLite de NuGet présente le comportement que vous avez décrit. Si vous souhaitez charger la version correcte pour l'architecture réelle que le runtime .NET a choisi d'exécuter votre application sur votre machine, vous pouvez donner au chargeur DLL une indication sur l'emplacement de la bibliothèque appropriée comme suit:

Ajoutez une déclaration pour l'appel de fonction kernel32.dll à SetDLLDirectory () avant votre 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);

Utilisez ensuite votre propre méthode pour déterminer le sous-répertoire correct pour trouver la version spécifique à l'architecture de «SQLite.Interop.dll». J'utilise le code suivant:

    [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));

même s'il s'agit d'un ancien article, j'aimerais partager la solution que j'ai trouvée ici: http://system.data.sqlite.org/index.html/info/54e52d4c6f

Si vous ne voulez pas lire tout le problème, la solution consiste à copier le fichier "msvcr100.dll" (qui se trouve dans le répertoire Windows \ System32) dans le même chemin que SQLite.Interop.dll.

Je vous conseille de lire le problème pour comprendre pourquoi et d'inclure le fichier dans votre configuration, mais pour l'installer uniquement si l'erreur se produit, je l'ai fait un composant facultatif sélectionnable dans les options de configuration.

HTH, Formentz

Comme le dit le wiki SQLite , le déploiement de votre application doit être:

Vous devez donc suivre les règles. Trouvez la DLL qui correspond à votre plate-forme cible et mettez-la à l'emplacement, décrit dans l'image. Les DLL peuvent être trouvées dans YourSolution / packages / System.Data.SQLite.Core.% Version% /.

J'ai eu des problèmes avec le déploiement d'applications, j'ai donc ajouté le bon SQLite.Interop.dll dans mon projet, le dossier x86 ajouté à AppplicationFolder dans le projet d'installation et ajouté des références de fichier à la DLL.

Vous pouvez également obtenir cette erreur si vous essayez d'exécuter une DLL 32 bits, dans un projet 64 bits.

Je l'ai obtenu lorsque j'ai placé le même fichier (SQLite.Interop.dll en version 32 bits) dans le dossier x86 et x64.

Si vous téléchargez le binaire correct pour SQLitepuis copiez-le SQLite.Interop.dlldans votre dossier Release ou Debug en fonction de l'option de génération de votre projet.

Je ne sais pas pourquoi cela n'a pas encore été inclus, mais j'ai dû faire la recherche et le découvrir par moi-même, alors j'espère que quelqu'un trouvera cette réponse et sera sauvé la peine. C'était pour une application WPF. Cela a bien fonctionné sur ma boîte de développement, mais n'a pas fonctionné sur l'ordinateur où je le copiais et a obtenu l' Unable to load DLL 'SQLite.Interop.dll'erreur. J'ai porté sur tous ses répertoires et fichiers associés, directement depuis mon dossier "Debug" vers cet autre ordinateur lorsque j'ai eu la même erreur que l'OP lorsque je l'ai exécuté. Mon dossier "bin" qui contenait mes DLL avait été copié dans "Debug \ bin" et tous étaient inclus, ainsi que mes fichiers d'application lorsque j'ai fait ma copie sur l'autre ordinateur en utilisant ce chemin, il ne manquait donc aucun fichier.

Ce que j'ai vu dans d'autres réponses ne s'applique pas:

• Je n'ai pas utilisé le package NuGet ni besoin de créer des dossiers x86 ou x64 qu'il semble que le package NuGet crée. Mes DLL (System.Data.SQLite et SQLite.Interop.dll, ainsi que System.Data.SQLite.config) se trouvent dans le dossier "bin" de mon projet et ont été copiées manuellement (créez le dossier "bin" dans l'Explorateur de solutions dans VS, collez les DLL dans ce dossier dans l'Explorateur Windows, utilisez Ajouter> Élément existant pour importer des fichiers dans le dossier / projet VS). Ensuite, je les référence en tant qu'assemblys référencés dans mon projet en utilisant cet emplacement ("Références"> "Ajouter une référence", et recherchez-en un, rincez, répétez pour le reste). Cela garantit que mon projet sait exactement où ils se trouvent.
• Je n'avais pas besoin de référencer un fichier DLL SQLite dans mon app.config ou même de toucher mon fichier MyProject.csproj.
• Je n'avais même pas besoin de spécifier un processeur particulier! La construction de mon projet est pour "Any CPU", même si je n'ai que des DLL mixtes ou 64 bits et que je ne fonctionnerai que sur Windows 7+, qui sont des systèmes d'exploitation 64 bits. (pas de DLL uniquement x86 / 32 bits uniquement)
• Je les spécifiais déjà comme "Contenu" et "copier si plus récent" pour ces DLL lorsque j'ai rencontré l'erreur de l'OP.

Ce que j'ai trouvé était ceci, à partir de https://system.data.sqlite.org/index.html/doc/trunk/www/faq.wiki#q20 :

(11) Pourquoi est-ce que j'obtiens une exception DllNotFoundException (pour "sqlite3.dll" ou "SQLite.Interop.dll") lorsque j'essaie d'exécuter mon application?

Soit la bibliothèque de liens dynamiques (DLL) nommée est introuvable, soit elle ne peut pas être chargée en raison de dépendances manquantes. Assurez-vous que la bibliothèque de liens dynamiques nommée se trouve dans le répertoire de l'application ou un répertoire le long du CHEMIN système et réessayez. En outre, assurez-vous que le redistribuable d'exécution Visual C ++ nécessaire a été installé, sauf si vous utilisez une bibliothèque de liens dynamiques qui a été créée de manière statique.

Soulignez le mien sur cette partie en gras à l'intérieur du paragraphe. L'ordinateur cible était récent et n'avait aucun programme chargé à l'exception de .NET 4.0. Une fois que j'ai installé C ++, il a pu terminer les commandes vers SQLite. Cela aurait dû être l'une des premières FAQ et une partie des pré-requis, mais il a été enterré au n ° 11. Mon ordinateur de développement l'avait déjà chargé parce qu'il était livré avec Visual Studio, c'est pourquoi cela a fonctionné, là-bas.

Téléchargement:
Visual C ++ redistribuable pour Visual Studio 2015:
https://www.microsoft.com/en-us/download/details.aspx?id=48145

Mise à jour 3 (mise à jour cumulative):
https://www.microsoft.com/en-us/download/details.aspx?id=53587

J'ai commencé à utiliser Costura.Fody pour empaqueter des assemblys (.net) et incorporer et précharger des DLL natives. Cela aide également plus tard, avec la distribution car vous pouvez envoyer un fichier.

1. Installez Costura Fody depuis Nuget.

2. Dans votre projet C #, créez un dossier appelé costrua32. Ajoutez-y toutes les DLL natives que vous souhaitez charger en C #.

3. Une fois que vous les avez ajoutés à ce dossier. Cliquez sur la fenêtre des propriétés et changez l'action de construction en "Ressource intégrée"

4. Enfin, vous devez modifier le fichier XML appelé FodyWeavers.xml comme suit. Ici, je spécifie d'abord la charge de la DLL sql. (notez que vous déposez le fichier .dll)

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

L'avantage de ceci est que vous n'avez pas à écrire d'événements avant ou après la génération, et le produit final est totalement encapsulé dans un fichier plus grand.

A également ajouté la DLL au projet de test (via Nuget Manager) et il l'a corrigé.

J'ai eu ce problème parce que Visual C ++ 2010 redistribuable n'est pas installé sur mon PC. Si vous n'avez pas déjà installé Visual c ++ 2010 redistribuable Téléchargez et installez ceci (vérifiez x86 ou 64 dll).

J'ai le même problème. Cependant, enfin, je peux le réparer. Actuellement, j'utilise Visual Studio 2013 Community Edition. J'utilise simplement Add-> Existing Item ... et je cherche où se trouvent les fichiers SQLite.Data.SQLite (mon cas est 'C: \ Program Files (x86) \ System.Data.SQLite \ 2013 \ bin'). N'oubliez pas de changer le type de ce que vous allez inclure dans les fichiers d'assemblage (* .dll; * .pdb) . Choisissez « SQLite.Interop.dll » dans ce dossier. À partir de là, je peux continuer sans aucun problème. Bonne chance à vous tous. ^ _ ^ PS Je crée une application de formulaire Web. Je n'ai pas encore essayé l'application de formulaire de fenêtre ou d'autres.

Essayez de définir la cible de la plate-forme sur x86 ou x64 (et non sur n'importe quel processeur) avant de créer: Projet-> Propriétés-> Générer-> Cible de plate-forme dans Visual Studio.

Copiez SQLite.Interop.dll dans le répertoire du projet.

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

Je me bats avec cela depuis longtemps, et, parfois, j'ai trouvé que le paramètre de test était incorrect. Voir cette image:

Je décoche simplement le paramètre de test et le problème disparaît. Sinon, l'exception se produira. J'espère que cela aidera quelqu'un. Je ne suis pas sûr que ce soit la cause première.

Copiez les fichiers "SQLite.Interop.dll" pour x86 et x64 dans le dossier de débogage. ces fichiers doivent être copiés dans les dossiers "x86" et "x64 dans le dossier de débogage.

Mon application est une application Web (ASP.NET MVC) et j'ai dû changer le pool d'applications pour s'exécuter LocalSystemau lieu de ApplicationPoolIdentity. Pour faire ça:

1. Ouvrez IIS Manager
2. Recherchez le pool d'applications sur lequel votre site s'exécute.
3. Cliquez sur Paramètres avancés dans les actions
4. Changer d'identité en LocalSystem

Je ne sais pas pourquoi cela résout le problème.

Je ne sais pas si c'est une bonne réponse, mais j'ai pu résoudre ce problème en exécutant mon application sous un AppDomain avec une identité de "Local System".

Je travaille sur une application console simple pour ajouter des données de test à une base de données SQLite et obtenais cette erreur. La configuration du projet est "Any CPU". Je l'ai corrigé en copiant le SQLite.Interop.dll dans le dossier bin \ debug. Une meilleure façon serait d'utiliser la méthode par @Wil, mais comment spécifiez-vous cela pour la configuration "Any CPU"?

Pourrait-il y avoir conflit pour l'assemblée? Vérifiez s'il existe une autre application avec un verrou de fichier sur la DLL.

Si c'est la raison, il devrait être facile d'utiliser un outil comme Process Explorer de Sysinternal pour découvrir le programme incriminé.

HTH, argile

Pour référence pour quiconque regarde cette question:

Si vous utilisez le package nuget, il installe une règle de génération qui effectue la copie pour vous. (voir sous System.Data.SQLite.Core.1.0.94.0 \ build - ou quelle que soit la version de Core que vous installez).

Le programme d'installation de nuget ajoute automatiquement la règle à votre fichier de projet.

Cela ne résout toujours pas le problème du cas de test. L' approche DeploymentItem ( https://stackoverflow.com/a/24411049/89584 ) est la seule chose qui semble fonctionner là-bas.

J'ai rencontré ce problème, dans une solution avec un projet Web WebAPI / MVC5 et un projet de test de fonctionnalité, qui tiraient tous deux du même projet d'accès aux données (ou «Core»). Comme beaucoup d'autres ici, j'utilise une copie téléchargée via NuGet dans Visual Studio 2013.

Ce que j'ai fait, c'est que dans Visual Studio, j'ai ajouté un dossier de solution x86 et x64 au test de fonctionnalité et aux projets Web. J'ai ensuite fait un Right Click | Add Existing Item...et ajouté la bibliothèque SQLite.interop.dll appropriée ..\SolutionFolder\packages\System.Data.SQLite.Core.1.0.94.0\build\net451\[appropriate architecture]pour chacun de ces dossiers. J'ai ensuite fait un Right Click | Properties, et je me suis mis Copy to Output Directoryà Always Copy. La prochaine fois que je devais exécuter mes tests de fonctionnalités, les tests se sont déroulés avec succès.