FluentNHibernate; SQLite; FileNotFoundException (System.Data.SQLite)

Question

J'ai fait un projet C#, et pourrait Couramment configurer pour SQLite sans même ajouter une référence à System.Data.SQLite.dll. Maintenant, lors d'une tentative d'un projet VB.NET , avec ou sans la référence, je reçois un

FileNotFoundException: Could not load file or assembly 'System.Data.SQLite' or one of its dependencies. The system cannot find the file specified.

Est-ce NHibernate ou FluentNHibernate la recherche de ce dll (?) Et comment se fait ils ne regardent pas les references? Ou qu'est-ce qui me manque?

BTW, il y a someting appelé "FusionLog", qui dit:

 
=== Pre-bind state information === 
LOG: User = PC\windowslogin 
LOG: DisplayName = System.Data.SQLite 
(Partial) 
LOG: Appbase = file:///(Project folder)./bin/Debug/ 
LOG: Initial PrivatePath = NULL 
Calling assembly : NHibernate, Version=3.0.0.4000, Culture=neutral, PublicKeyToken=aa95f207798dfdb4. 
=== 
LOG: This bind starts in default load context. 
LOG: Using application configuration file: (project folder/name).vshost.exe.Config 
LOG: Using machine configuration file from C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\config\machine.config. 
LOG: Policy not being applied to reference at this time (private, custom, partial, or location-based assembly bind). 
LOG: The same bind was seen before, and was failed with hr = 0x80070002. 

Answer 1

Vérifiez le dossier bin de vos projets C#, la DLL peut avoir trouvé son chemin là-dedans. S'il a été supprimé, il aura la même erreur, ou il sera copié là-bas lors de la construction. Si c'est le dernier, il réalise la dépendance et la copie du fichier.

L'erreur ci-dessus se produit lorsque la DLL n'est pas trouvée dans l'un des chemins de recherche, ou le GAC. Les chemins de recherche incluent le dossier bin (en premier) et d'autres dossiers système.

Pour résoudre le problème VB, faites référence à l'assembly SQLite et assurez-vous que vous avez activé "CopyLocal". À moins que vous n'ayez ceci, VS ne copiera pas l'assembly dans le chemin de sortie car vous ne le référenciez pas explicitement. NHibernate chargerait dynamiquement cet assembly.