5

Je n'arrive pas à faire fonctionner le pilote SQLite dans ma sessionfactory.FluentNhibernate et SQLite

J'ai téléchargé SQLite 1.0.48 de http://sqlite.phxsoftware.com/

J'ai ajouté les références à System.Data.SQLite dans mon projet de tests.

public static IPersistenceConfigurer GetSqlLiteConfigurer() 
     { 
      try 
      { 
       return SQLiteConfiguration 
       .Standard 
       .InMemory(); 
      } 
      catch (Exception ex) 
      { 
       throw ex; 
      } 
     } 

Voilà comment je produis le configurateur

Le problème est quand je construis mon SessionFactory je reçois l'erreur suivante:

NHibernate.HibernateException: The IDbCommand and IDbConnection implementation in the assembly System.Data.SQLite could not be found. Ensure that the assembly System.Data.SQLite is located in the application directory or in the Global Assembly Cache. If the assembly is in the GAC, use <qualifyAssembly/> element in the application configuration file to specify the full name of the assembly. 
at NHibernate.Driver.ReflectionBasedDriver..ctor(String driverAssemblyName, String connectionTypeName, String commandTypeName) 
at NHibernate.Driver.SQLite20Driver..ctor() 

J'ai essayé de changer la version SQLite, mais n'a pas résoudre le problème.

Je ne trouve pas quel est le problème et j'y travaille depuis 2 jours maintenant. Faites-moi savoir si vous avez besoin de plus d'informations.

Merci pour l'aide!

Charles

Répondre

7

Je fixe mon problème en obtenant le fichier System.Data.SQLite.dll qui se trouve dans le répertoire SVN FluentNHibernate.

Cela fonctionne maintenant très bien.

je aurais dû vérifier plus tôt;)

+0

Merci. Cela a résolu le problème pour moi. – statenjason

+0

Maintenant disponible en package NuGet http: // nuget.org/List/Packages/SQLitex64 –

10

Quand je suis tombé sur cette question, il a été causé par l'exécution ayant la propriété de processeur de mon application à l'ensemble anycpu et en cours d'exécution sur un système 64 bits. Pour corriger le problème, j'ai défini la propriété de mon processeur d'applications sur x86. Je ne pense pas que le fichier System.Data.SQLite.dll puisse être exécuté sous un processus x64.

+2

System.Data.SQLite.dll * est * disponible pour x64, c'est juste un autre assemblage (qui est inclus dans le répertoire x64) –

+0

+1 cela a résolu le problème pour moi (même en utilisant le x64 dll de SQLite ne semble pas fonctionner) – Ben

+0

travaillé pour moi aussi – Kevin

0

Je rencontre le même problème sur une machine de construction. Cela fonctionne correctement lorsque j'ouvre le projet avec Visual Studio, mais lorsque j'exécute mstest.exe, il échoue avec l'erreur ci-dessus. Il échoue également sur ma machine de développement local lorsque je cours en ligne de commande. Process Monitor ne montre aucune tentative de localiser le fichier par mstest.exe.

La machine de génération est de 32 bits, ma machine locale est de 64 bits. L'assemblage que nous utilisons est celui du tronc NHibernate Fluent. MISE À JOUR: Compris: mstest.exe ne copiait pas tous les assemblys lorsqu'il était exécuté à partir de la ligne de commande. J'ai mis à jour localtestrun.config pour les inclure sous Deployment. Vous ne savez pas pourquoi le comportement est différent de celui de l'EDI et du programme de test de ligne de commande.

+0

Salut, je suis le problème exact ! Ma machine de construction est également 64 bits, c'est la seule différence. Mes tests échouent aussi lorsqu'ils sont exécutés localement, via une ligne de commande, mais passent par VS. Comment as-tu réparé ça s'il te plait? Que voulez-vous dire par "J'ai mis à jour localtestrun.config pour les inclure sous Déploiement" et comment puis-je faire cela? – iamserious

+0

@iamserious si je me souviens pas tous les assemblages requis ont été copiés. En utilisant les paramètres de déploiement dans votre configuration de test, vous pouvez vous assurer que tous les bits nécessaires sont présents pour l'exécution. –

+0

Colin, d'accord, merci! – iamserious

1

Cochez cette case si vous utilisez la version 4.0 comme infrastructure cible. Le pilote ADO actuellement (1.0.66) prend en charge seulement 3.5.