Impossible de charger DLL 'SQLite.Interop.dll'
Périodiquement, je reçois 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 sous VS2010, OS Win7 64.
Dès que l'exception commence à apparaître, elle apparaît constamment - dans les applications de débogage et de publication et d'exécution dans ou en dehors de VS.
La seule façon de l'arrêter est la fermeture de session et la connexion. L'exception n'est pas levée et la DLL est chargée. Cela peut fonctionner pendant des jours, mais ensuite cela peut casser à nouveau.
Quelqu'un a-t-il déjà vu quelque chose comme cela et y a-t-il une solution à cela?
Je sais que je suis en retard pour la fête, mais j'ai eu ce problème juste après avoir descendu le dernier x86/x64 aujourd'hui (version 1.0.88.0). Mon serveur local IIS sous VS2012 exécute le mode 32 bits par défaut et il n'existe aucun moyen simple de passer à x64. Mon serveur de production fonctionne en 64 bits.
Quoi qu'il en soit, j'ai installé le package NuGet sur un projet DLL et j'ai eu cette erreur. Ce que je devais faire pour le faire fonctionner, je devais aussi l'installer sur le site principal projet, aussi. Même si cela ne touche pas du tout les classes SQLite.
Je suppose que SQLite utilise l'entrée Assembly pour détecter la version d'Interop à charger.
J'ai eu ce problème parce qu'une dll que j'utilisais avait Sqlite en tant que dépendance (configuré dans NuGet avec uniquement le paquet principal Sqlite.). Le projet compile et copie toutes les dll-s SQLite à l'exception du fichier 'SQLite.Interop.dll' (dossier x86 et x64).
La solution était très simple: ajoutez simplement le paquet Sqlite.Core en tant que dépendance (avec NuGet) au projet que vous construisez/exécutez et la dll-s sera copiée.
J'ai eu le 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:
- Ouvrez le concepteur de projet dans Visual Studio. Des détails sur la façon de le faire peuvent être trouvés ici .
- Cliquez sur l'onglet Construire.
- Désactivez l'option
prefer 32-bit.
Alternativement, vous pouvez simplement définir la cible de la plateforme sur x86 ou x64. Je pense que ce problème est dû à la bibliothèque System.Data.SQLite qui utilise la plate-forme cible pour obtenir l'emplacement du fichier 'SQLite.Interop.dll'.
MISE À JOUR:
Si le concepteur de projet ne peut pas être contacté, ouvrez simplement le fichier projet (*.csproj) à partir d'un éditeur de texte et ajoutez la valeur <Prefer32Bit>false</Prefer32Bit> dans la balise <PropertyGroup>...</PropertyGroup>.
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>
Voici comment 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 DLL 'SQLite.Interop.dll'".
À la différence du fichier .csproj du projet, il s'agissait de 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, je n'ai pas reçu l'exception. Les fichiers DLL ont été vidés dans les dossiers Debug\x64 (etc.) appropriés.
Lorsque vous obtenez cet état, essayez d’effectuer une opération de reconstruction globale. Si cela résout le problème, vous pouvez avoir le même problème que j'ai eu.
Quelques antécédents (à ma connaissance) :
SQLite a 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 ajoute 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’assemblée gérée recherchera les assemblages spécifiques à la plate-forme dans les dossiers\x86 et\x64. Vous pouvez en voir plus à ce sujet ici . L'exception est que cet assemblage géré tente de trouver l'élément pertinent (SQLite.Interop.dll) 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 référence la bibliothèque de classes et la bibliothèque de classes référence SQLite (installée via Nuget).
Le problème pour moi était que lorsque je ne modifiais que l'application WPF, VS tentait de reconstruire partiellement (réalisant que la dll dépendante n'avait pas changé). Quelque part dans ce processus, VS nettoie le contenu des dossiers\x86 et\x64 (suppression de SQLite.Interop.dll). Lorsque je fais une reconstruction complète, VS copie les dossiers et leur contenu correctement.
Ma solution :
Pour résoudre ce problème, j'ai fini par ajouter un processus de post-génération utilisant xcopy pour forcer la copie des dossiers\x86 et\x64 de la bibliothèque de classes dans le répertoire\bin de mon projet WPF.
Alternativement, vous pouvez faire des choses plus sophistiquées avec les répertoires de configuration/sortie de construction.
J'avais le même problème sous Visual Studio Express 2013. J'ai essayé plusieurs solutions mentionnées ici et ailleurs, mais en vain. J'espère que ce correctif aide les autres.
Je l'ai corrigé en utilisant DeploymentItem attribut 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
}
}
Ainsi, le SQLite.Interop.dll nécessaire est copié dans le répertoire x86 du dossier "TestResults" approprié.
Tout est vert. Tout est bon.
Mettre à jour NuGet à partir de Tools -> Extension and updates et réinstaller SQLite.Core à l’aide de la commande PM> Update-Package -reinstall System.Data.SQLite.Core l’a corrigé.
Ainsi, après avoir ajouté NuGet, le déploiement ne copie pas les Interops. Vous pouvez ajouter ceci à votre fichier csproj et cela devrait résoudre ce problème:
<PropertyGroup>
<ContentSQLiteInteropFiles>true</ContentSQLiteInteropFiles>
<CopySQLiteInteropFiles>false</CopySQLiteInteropFiles>
<CleanSQLiteInteropFiles>false</CleanSQLiteInteropFiles>
<CollectSQLiteInteropFiles>false</CollectSQLiteInteropFiles>
</PropertyGroup>
Si vous regardez dans le code source de NuGet pour SQLite, vous pouvez voir ce qu’ils font spécifiquement. Cela m'a permis de déployer un déploiement avec ASP.Net Core.
J'ai eu un problème similaire dans une solution de plusieurs projets. Le fichier SQLite.Interop.dll était nécessaire pour l’un des plug-in distribués avec le logiciel utilisant ClickOnce.
En ce qui concerne le débogage dans Visual Studio, tout fonctionnait correctement, mais la version déployée ne contenait pas les dossiers x86/et x64/contenant cette DLL.
La solution pour que cela fonctionne après le déploiement à l'aide de ClickOnce consistait à créer ces deux sous-dossiers dans le projet de démarrage de la solution (également celui en cours de publication), à y copier les DLL et à les définir en tant que Content Copy Always.
De cette manière, 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 no-GAC-play-around.
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 possède le DLL requis pour la connexion SQLite.
Donc, je mets simplement un script post-build dans ma solution couche de données et tout a bien fonctionné.
TL; DR;
- Définissez tous les projets de votre solution sur
x86oux64dans les options de construction. Ajoutez les
Post-Build-Scriptsuivants au projet avec leSQLite nuget Package:xcopy "$(TargetDir)x64" "$(SolutionDir)bin\Debug\" /y
Bien sûr, vous devez modifier le script pour les constructions Release Build et x86.
STL; DR;
Placez votre SQLite.Interop.dll à côté du fichier *.exe.
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 ordinateur, vous pouvez donner au chargeur DLL un indice sur l'emplacement de la bibliothèque correcte, 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 bon sous-répertoire afin de 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 billet, 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 conseillerais de lire le problème pour comprendre pourquoi et d’inclure le fichier dans votre configuration mais de ne l’installer que si l’erreur se produit, j’en ai fait un composant facultatif sélectionnable dans les options de configuration.
HTH, Formentz
Vous pouvez également obtenir cette erreur si vous essayez d'exécuter une dll 32 bits dans un projet 64 bits.
Je l'ai eu lorsque j'ai placé le même fichier (SQLite.Interop.dll en version 32 bits) dans les dossiers x86 et x64.
Je ne sais pas pourquoi cela n'a pas encore été inclus, mais je devais faire la recherche et le découvrir moi-même, alors j'espère que quelqu'un trouvera cette réponse et sera sauvé. C'était pour une application WPF. Cela a bien fonctionné sur ma boîte de dialogue Dev, mais pas sur l'ordinateur sur lequel je la copiais et j'ai obtenu l'erreur Unable to load DLL 'SQLite.Interop.dll'. J'ai transféré tous les répertoires et fichiers associés directement à partir de 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 je copiais sur l'autre ordinateur en utilisant ce chemin, de sorte qu'il ne manquait aucun fichier.
Ce que j'ai vu dit dans d'autres réponses qui ne s'appliquent pas:
- Je n'ai pas utilisé le package NuGet ni besoin de créer des dossiers x86 ou x64 créés par le package NuGet. 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éer un dossier "bin" dans l'Explorateur de solutions dans VS, collez les DLL dans ce dossier de l’explorateur Windows, utilisez la commande Ajouter> Elément existant pour importer les fichiers dans le dossier/projet VS). Ensuite, je les référence en tant qu’assemblées référencées dans mon projet en utilisant cet emplacement ("Références"> "Ajouter une référence", et naviguez jusqu’à un, rinse, 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 de fichier SQLite DLL dans mon app.config ni même de toucher mon fichier MyProject.csproj.
- Je n'ai même pas eu besoin de spécifier un processeur particulier! La construction de mon projet concerne "Tous les processeurs", même si je n'ai que des DLL mixtes ou 64 bits et que je ne fonctionnerai que sous Windows 7+, systèmes d'exploitation 64 bits. (pas de DLL uniquement pour x86/32 bits)
- Je les spécifiais déjà comme "Contenu" et "Copier si plus récent" pour ces DLL lorsque j'ai rencontré l'erreur du PO.
Ce que j’ai trouvé est le suivant: https://system.data.sqlite.org/index.html/doc/trunk/www/faq.wiki#q20 :
(11) Pourquoi ai-je une exception DllNotFoundException (pour "sqlite3.dll" ou "SQLite.Interop.dll") lors de la tentative d'exécution de mon application?
La bibliothèque de liens dynamiques nommée (DLL) ne peut pas être localisée ou 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 dans un répertoire du chemin PATH du système, puis réessayez. Assurez-vous également que le programme d’exécution redistribuable Visual C++ nécessaire a été installé. à moins que vous n'utilisiez une bibliothèque de liens dynamiques construite de manière statique.
J'insiste particulièrement sur cette partie en gras à l'intérieur du paragraphe. L'ordinateur cible était récent et aucun programme n'était chargé à l'exception de .NET 4.0. Une fois que j'ai installé C++, il a été capable de compléter les commandes de SQLite. Cela aurait dû être l’une des premières FAQ et une partie des prérequis, mais elle a été enterrée à la # 11. Mon ordinateur de développement l’avait déjà chargé parce qu’il était livré avec Visual Studio, c’est pourquoi il a fonctionné.
Télécharger:
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
Si vous téléchargez le fichier binaire correct pour SQLite, copiez SQLite.Interop.dll dans votre version ou Déboguer en fonction de votre option de construction du projet.
J'ai commencé à utiliser Costura.Fody pour conditionner des assemblages (.net) et incorporer et précharger des dll natives. Cela aidera également plus tard, avec la distribution car vous pouvez envoyer un fichier.
Installez Costura Fody de Nuget.
Dans votre projet C #, créez un dossier appelé costrua32. Ajoutez-y les dll natives que C # doit charger.
Une fois que vous les avez ajoutés à ce dossier. Cliquez sur la fenêtre de propriétés et changez l'action de construction en "Ressource incorporée"
Enfin, vous devez modifier le fichier XML appelé FodyWeavers.xml comme suit. Ici, je spécifie de charger le dll sql en premier. (notez que vous déposez le fichier .dll)
Weavers Costura PreloadOrder SQLite.Interop tbb_debug tbb /PreloadOrder> /Costura /Weavers
L'avantage de cela 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 volumineux.
Comme le SQLite wiki , le déploiement de votre application doit être:
Donc, vous devez suivre les règles. Trouvez la DLL correspondant à votre plate-forme cible et mettez-la à l'emplacement indiqué dans l'image. Les dll peuvent être trouvés dans YourSolution/packages/System.Data.SQLite.Core.% Version% /.
J'ai eu des problèmes avec le déploiement d'applications, alors je viens d'ajouter le droit SQLite.Interop.dll dans mon projet, le dossier x86 ajouté à AppplicationFolder dans le projet d'installation et les références de fichier à dll.
J'ai le même problème. Cependant, finalement, je peux le réparer. Actuellement, j'utilise Visual Studio 2013 Community Edition. Je viens d'utiliser Ajouter-> Article existant ... et naviguez jusqu'à l'emplacement des 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 Assembly Files (* .dll; * .pdb). Choisissez "SQLite.Interop.dll" dans ce dossier. À partir de là, je peux continuer sans aucun problème. Bonne chance à vous tous. ^ _ ^ P.S. Je crée une application de formulaire Web. Je n'ai pas encore essayé l'application Windows ou d'autres.
Également ajouté la dll au projet de test (via Nuget Manager) et l'a corrigé.
Essayez de définir la cible de la plate-forme sur x86 ou x64 (et non sur Tout processeur) avant de générer: Projet-> Propriétés-> Construire-> Cible de la 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
Cela fait longtemps que je lutte avec cela et j’ai parfois constaté que les paramètres de test étaient incorrects. Voir cette image: 
Je viens de décocher le réglage du test et le problème disparaît. Sinon, l'exception se produira. J'espère que cela aidera quelqu'un. Pas sûr que ce soit la cause première.
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 "système local".
En bref
Pour que cela fonctionne également avec NCrunch , j'ai dû ajouter les versions Interop.dll fournies avec le package NuGet en tant que fichiers supplémentaires dans la configuration de NCrunch .
Mon cas
J'avais une solution C # avec un projet directement dépendant de SQLite (une bibliothèque d'assistance) et un projet de test unitaire utilisant cette bibliothèque d'assistance. J'avais installé System.Data.SQLite.Core version 1.0.97.0 en tant que package NuGet.
Dans mon cas, le solution de contournement fournie par Marin l'a fait fonctionner dans Visual Studio et également dans CI. Cependant, cela fournirait toujours des erreurs dans NCrunch.
Dans la configuration de NCrunch, j'ai ajouté le chemin suivant dans "Fichiers supplémentaires à inclure" dans les paramètres de projets de tests unitaires:
..\packages\System.Data.SQLite.Core.1.0.97.0\build\net45\**.dll
Je travaille sur une application console simple pour ajouter des données de test à une base de données SQLite et cette erreur se produisait. La configuration du projet est "Tout processeur". Je l'ai corrigé en copiant SQLite.Interop.dll dans le dossier bin\debug. Un meilleur moyen serait d'utiliser la méthode de @Wil, mais comment spécifiez-vous cela pour la configuration "Tout processeur"?
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 du dossier de débogage.
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 tel que Process Explorer de Sysinternal pour découvrir le programme incriminé.
HTH, Argile
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 dans Visual Studio, j'ai ajouté un dossier de solutions x86 et x64 aux tests de fonctionnalités et aux projets Web. J'ai ensuite fait un Right Click | Add Existing Item... et ajouté la bibliothèque SQLite.interop.dll appropriée à partir de ..\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 mis Copy to Output Directory sur Always Copy. La prochaine fois que j'ai eu besoin d'exécuter mes tests de fonctionnalité, les tests ont été exécutés avec succès.
Pour référence pour ceux qui regardent cette question:
Si vous utilisez le paquet Nuget, il installe une règle de construction qui effectue la copie à votre place. (voir sous System.Data.SQLite.Core.1.0.94.0\build - ou n’importe quelle 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 scénario de test. L'approche DeploymentItem ( https://stackoverflow.com/a/24411049/89584 ) est la seule chose qui semble fonctionner ici.
J'ai eu ce problème parce que Visual C++ 2010 redistribuable pas installé dans mon PC.Si vous n'avez pas déjà installé Visual C++ 2010 redistribuable Télécharger et l'installer (vérifier x86 ou 64 dll).
J'ai rencontré ce problème moi-même, mais il s'est avéré que c'était une autre cause:
System.DllNotFoundException was caught
Unable to load DLL 'SQLite.Interop.dll': Access is denied.
Dans ce cas, le code a été appelé (indirectement) à partir d'un service Web hébergé par IIS (configuré pour la génération x86). Je l'ai finalement retrouvé dans le pool d'applications d'IIS: à l'origine, j'utilisais "ASP.NET V4.0 Integrated" (ce qui a entraîné cette erreur), mais je l'ai changé en "DefaultAppPool", le problème a disparu.
(Phew!)
Dans le paquet Nuget de SQLLite Core, il y a un fichier System.Data.SQLite.Core.targets. Incluez simplement ceci dans tous les projets qui utilisent la bibliothèque this et toutes les bibliothèques qui ont utilisé votre bibliothèque.
Dans vos fichiers .csproj ou .vbproj, ajoutez: Chaque fois que vous compilerez dans votre bin, les répertoires x86 et x64 seront ajoutés avec le fichier SQLite.Interop.dll.
Je voulais poster ici à cause de la complexité de ce problème. Ma solution a été de revenir à .Net 4.0. Je teste depuis 3 jours et je n’ai pas réussi à faire fonctionner System.Data.SQLite.Core.1.0.98.0 avec .Net 4.5 ou .Net 4.5.1.
Les tests étaient exhaustifs sur 3 ordinateurs, 2 serveurs et un dev PC. Je n'ai pas pu arriver à la source du problème. J'ai essayé de modifier le fichier .vsproj. J'ai ajouté le SQLite.interop.dll à tous les dossiers pratiquement. J'ai appliqué le package à tous les dossiers GAC, puis supprimé et réappliqué individuellement. Finalement enlevé.
J'ai System.Data.SQLite.Core.1.0.98.0 qui fonctionne avec .Net 4.0. J'ai l'intention de continuer d'essayer la migration, mais je pense que je vais commencer par un nouveau projet et voir si je peux le faire fonctionner de cette manière. C’était à l’origine une application Web .Net 3.5, et au cours de mes voyages, j’ai trouvé une bonne quantité d’informations qui faisaient toujours référence à ce cadre.
Mon application est une application Web (ASP.NET MVC) et j'ai dû modifier le pool d'applications pour qu'il s'exécute sous LocalSystem au lieu de ApplicationPoolIdentity. Pour faire ça:
- Ouvrir IIS Manager
- Recherchez le pool d'applications sous lequel votre site est exécuté.
- Cliquez sur Paramètres avancés dans les actions.
- Changer l'identité en
LocalSystem
Je ne sais pas pourquoi cela résout le problème.
Donc, mon problème était que SQLite essayait de charger au moment du design dans WPF. Comme je ne me souciais que de l’environnement x86, j’ai défini cette préférence sur le processeur et copié SQLite.Interop.dll à partir du package Nuget dans le répertoire racine de la solution. Redémarrez la solution et tous les problèmes ont disparu. Par conséquent, si vous rencontrez des problèmes de conception, placez la bibliothèque dans le répertoire racine de votre solution.
De plus, je rencontrais un problème similaire au moment de l'exécution. Je devais donc placer une copie de SQLite.Interop.dll dans mon projet et la définir pour la copie si elle était plus récente dans les propriétés. Il semble que les dossiers x86 et x64 fournis soient complètement inutiles. Un examen plus approfondi est nécessaire, mais dans l’ensemble ... il est simplement plus facile de référencer manuellement SQLite dans votre projet que d’utiliser un package Nuget.
De plus, le FAQ officiel indique ce qui suit:
(20) Lorsque le projet System.Data.SQLite est compilé et exécuté à partir de Visual Studio, pourquoi une exception DllNotFoundException ou BadImageFormatException (pour "sqlite3.dll" ou "SQLite.Interop.dll") est-elle utilisée lors de la tentative d'exécution ou déboguer l'application?
Lors de la compilation et de l'exécution d'une solution à partir de Visual Studio qui utilise le projet System.Data.SQLite (y compris le projet de test), il est très important de sélectionner la configuration de génération et la plate-forme appropriées. Tout d’abord, les applications gérées à déboguer dans Visual Studio ne peuvent pas utiliser l’Assembly en mode mixte (c’est-à-dire qu’il est toujours compilé dans le répertoire de sortie de la construction spécifique à la plate-forme). Cela est nécessaire pour prendre en charge correctement la création de fichiers binaires pour plusieurs plates-formes utilisant les mêmes fichiers de projet source. Par conséquent, seules les configurations de génération "DebugNativeOnly" ou "ReleaseNativeOnly" doivent être sélectionnées lors de l'exécution d'une application gérée à l'intérieur de Visual Studio reposant sur l'assembly System.Data.SQLite. Ces configurations de construction contiennent une étape de post-génération personnalisée qui copie l’Assembly natif requis dans le répertoire de sortie géré (pour permettre l’exécution des fichiers binaires gérés sur place). Toutefois, cette étape de post-génération ne sera effectuée que si la plate-forme sélectionnée correspond à celle du système d'exploitation (par exemple, "Win32" pour Windows 32 bits et "x64" pour Windows 64 bits). Par conséquent, il est recommandé de vérifier la plate-forme de génération sélectionnée par rapport au système d'exploitation avant de tenter d'exécuter un projet géré dans la solution.
https://system.data.sqlite.org/index.html/doc/trunk/www/faq.wiki#q2
Ma situation était un peu unique. J'exécutais une application à l'intérieur d'un conteneur de menu fixe et je continuais à avoir l'erreur suivante
System.DllNotFoundException: Impossible de charger la bibliothèque partagée 'SQLite.Interop.dll' ou l'une de ses dépendances. Afin de faciliter le diagnostic des problèmes de chargement, envisagez de définir la variable d’environnement LD_DEBUG: libSQLite.Interop.dll: impossible d’ouvrir le fichier objet partagé: aucun fichier ni répertoire de ce type
Donc j'ai mis LD_DEBUG = libs pour trouver quels dossiers System.Data.SQLite.dll cherchait SQLite.Interop.dll .
Vous pouvez trouver des informations sur le réglage LD_DEBUG ici: http://www.bnikolic.co.uk/blog/linux-ld-debug .html
Une fois que j'ai fait cela, j'ai réalisé que SQLite.Interop.dll se trouvait très bien. La DLL qui n'était pas trouvée était libSQLite.Interop.dll . J'aurais dû lire le message d'erreur en entier.
Heures de googler plus tard, j'ai trouvé ceci guide sur la façon de compiler le DLLmanquant à partir du code source SQLite.
Notez que le fichier manquant était libSQLite.Interop.dll.so
Quoi qu'il en soit, lorsque vous compilez le code source, vous obtenez libSQLite.Interop.so que vous devez renommer en libSQLite.Interop. .dll.so et mettez-le dans le répertoire de recherche dans lequel vous pouvez trouver en définissant LD_DEBUG .
Pour moi, le répertoire que System.Data.SQLite.dll cherchait était /usr/lib/x86_64-linux-gnu/
En développant la réponse de Kugel qui fonctionnait pour moi (VS2015 Enterprise) en utilisant SQLite à partir d’une dll, le package Nuget peut être supprimé du projet principal après la construction et les tests:
1.Installez le paquet Nuget dans le projet principal.
Install-Package System.Data.SQLite
2.Construisez une application et testez le fonctionnement de votre connexion SQLite:
select * from sqlite_master
3. Désinstallez le package Nuget à partir de la version principale.
UnInstall-Package System.Data.SQLite
4. Supprimez manuellement les références DLL pour SQLite et EntityFramework:
System.Data.SQLite
System.Data.SQLite.EF6
System.Data.SQLite.Linq
Supprimez les références XML du fichier xml "packages.config" du projet principal.
Cela a fonctionné pour moi et garde mon projet propre.
Le mien ne fonctionnait pas non plus pour les tests unitaires et, pour une raison quelconque, la réponse de Michael Bromley concernant l'attribut DeploymentItem ne fonctionnait pas. Cependant, je l'ai fait fonctionner en utilisant les paramètres de test. Dans VS2013, ajoutez un nouvel élément à votre solution, recherchez "paramètres" et sélectionnez le fichier de modèle "Paramètres de test". Nommez-le "SqliteUnitTests" ou quelque chose et ouvrez-le. Sélectionnez "Déploiement" sur la droite, et ajoutez un répertoire/fichier. Ajoutez des chemins/répertoires à votre fichier SQLite.Interop.dll. Pour moi, j'ai ajouté deux chemins, un pour Project\bin\Debug\x64 et Console\bin\Debug\x86. Vous pouvez également vouloir ajouter votre fichier Sqlite, selon la manière dont vous souhaitez que votre test/solution unitaire accède au fichier.