Okresowo otrzymuję następujący wyjątek:

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

Używam 1.0.82.0. wersja, instalując go z nugetem w VS2010, OS Win7 64.

Gdy wyjątek zacznie się pojawiać, pojawia się stale - podczas debugowania, wydawania i uruchamiania aplikacji w VS lub poza nią.

Jedynym sposobem, aby to zatrzymać, jest wylogowanie i zalogowanie. Wyjątek nie jest zgłaszany i ładowana jest biblioteka dll. Może działać przez kilka dni, ale potem może się zepsuć.

Czy ktoś widział coś takiego i czy istnieje na to rozwiązanie?

Wiem, że jestem spóźniony na imprezę, ale miałem ten problem zaraz po tym, jak ściągnąłem dzisiaj najnowszą wersję x86 / x64 (wersja 1.0.88.0). Moje lokalne usługi IIS w VS2012 domyślnie działają w wersji 32-bitowej i nie ma łatwego sposobu na przejście na x64. Mój serwer produkcyjny działa w wersji 64-bitowej.

W każdym razie zainstalowałem pakiet NuGet w projekcie DLL i dostałem ten błąd. To, co musiałem zrobić, aby działało, musiałem również zainstalować w głównym projekcie witryny . Nawet jeśli w ogóle nie dotyka klas SQLite.

Domyślam się, że SQLite używa zestawu wpisów do wykrywania, która wersja Interop ma zostać załadowana.

Miałem ten problem, ponieważ dll, którego używałem, miał Sqlite jako zależność (skonfigurowaną w NuGet tylko z głównym pakietem Sqlite). Projekt kompiluje i kopiuje wszystkie pliki DLL Sqlite oprócz „SQLite.Interop.dll” (zarówno folder x86, jak i x64).

Rozwiązanie było bardzo proste: wystarczy dodać pakiet Sqlite.Core jako zależność (z NuGet) do projektu, który budujesz / uruchamiasz, a dll-s zostaną skopiowane.

Miałem ten sam problem podczas korzystania z SQLite w projekcie WPF, którego celem była platforma Any CPU. Naprawiłem to, wykonując następujące kroki:

1. Otwórz projektanta projektu w Visual Studio. Szczegółowe informacje na temat tego można znaleźć tutaj .
2. Kliknij kartę Kompilacja.
3. Wyłącz prefer 32-bitopcję.

Alternatywnie możesz po prostu ustawić docelową platformę na x86lub x64. Myślę, że ten problem jest spowodowany przez System.Data.SQLitebibliotekę korzystającą z platformy docelowej, aby uzyskać lokalizację pliku „SQLite.Interop.dll”.

AKTUALIZACJA:

W przypadku, gdy nie można dotrzeć do projektanta, wystarczy otworzyć *.csprojplik project ( ) z edytora tekstu i dodać wartość <Prefer32Bit>false</Prefer32Bit>do <PropertyGroup>...</PropertyGroup>znacznika.

Przykładowy kod

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

Tak to naprawiłem w moim projekcie.

Działało, a gdy kolega przesłał zmiany, otrzymałem wyjątek „Nie można załadować biblioteki DLL„ SQLite.Interop.dll ”.

Różnicując plik .csproj projektu, był on w wersji NON-WORKING:

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

I to właśnie miała wersja WORKING:

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

Po cofnięciu nie otrzymałem wyjątku. Pliki DLL zostały zrzucone do odpowiednich folderów Debug \ x64 (itp.).

Tak więc po dodaniu NuGet wdrożenie nie kopiuje Interops. Możesz dodać to do pliku csproj i powinno to naprawić to zachowanie:

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

Jeśli zajrzysz do źródła NuGet dla SQLite, możesz zobaczyć, co konkretnie robią. To pozwoliło mi uzyskać wdrożenie współpracujące z ASP.Net Core.

Gdy znajdziesz się w tym stanie, spróbuj wykonać Przebuduj wszystko. Jeśli to rozwiąże problem, możesz mieć ten sam problem, co ja.

Trochę tła (moje rozumienie) :

• SQLite ma 1 zespół zarządzany (System.Data.SQLite.dll) i kilka zestawów specyficznych dla platformy (SQLite.Interop.dll). Podczas instalowania SQLite z Nuget, Nuget doda zestawy specyficzne dla platformy do twojego projektu (w kilku folderach: \ x86, \ x64) i skonfiguruje te pliki dll do „Zawsze kopiuj”.

• Po załadowaniu zespół zarządzany wyszuka zestawy specyficzne dla platformy w folderach \ x86 i \ x64. Możesz zobaczyć więcej na ten temat tutaj . Wyjątkiem jest ten zarządzany zestaw, który próbuje znaleźć odpowiedni (SQLite.Interop.dll) w tych folderach (i kończy się niepowodzeniem).

Mój scenariusz :

W moim rozwiązaniu mam 2 projekty; aplikacja WPF i biblioteka klas. Aplikacja WPF odwołuje się do biblioteki klas, a biblioteka klas odwołuje się do SQLite (instalowanego przez Nuget).

Problemem było dla mnie, gdy modyfikuję tylko aplikację WPF, VS próbuje wykonać częściową przebudowę (zdając sobie sprawę, że zależna biblioteka dll się nie zmieniła). Gdzieś w tym procesie VS czyści zawartość folderów \ x86 i \ x64 (zdmuchując SQLite.Interop.dll). Kiedy wykonuję pełny Przebuduj wszystko, VS poprawnie kopiuje foldery i ich zawartość.

Moje rozwiązanie :

Aby to naprawić, dodałem proces post-build przy użyciu xcopy, aby wymusić kopiowanie folderów \ x86 i \ x64 z biblioteki klas do mojego katalogu projektu \ bin WPF.

Alternatywnie, możesz robić bardziej wymyślne rzeczy z katalogami konfiguracji / wyjścia kompilacji.

Miałem ten sam problem z uruchomieniem Visual Studio Express 2013. Wypróbowałem kilka rozwiązań wymienionych tutaj i gdzie indziej, ale bezskutecznie. Mam nadzieję, że ta poprawka pomoże innym.

Naprawiłem to za pomocą DeploymentItematrybutu w mojej klasie testowej, która testuje usługę opartą na SQLite.

Przykład:

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

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

Powoduje to konieczność SQLite.Interop.dllskopiowania do x86katalogu w odpowiednim folderze „TestResults”.

Wszystko jest zielone. Wszystko jest dobrze.

Aktualizacja NuGet Tools -> Extension and updatesi ponowna instalacja SQLite.Core za pomocą polecenia PM> Update-Package -reinstall System.Data.SQLite.Corenaprawiły to dla mnie.

Miałem podobny problem w rozwiązaniu z wieloma projektami. SQLite.Interop.dll był niezbędny dla jednej z wtyczek dystrybuowanych wraz z oprogramowaniem za pomocą ClickOnce.

W przypadku debugowania w Visual Studio wszystko działało dobrze, ale we wdrożonej wersji brakowało folderów x86 / i x64 / zawierających tę bibliotekę DLL.

Rozwiązaniem, aby działało po wdrożeniu za pomocą ClickOnce, było utworzenie w projekcie startowym rozwiązania (również w tym publikowanym) tych dwóch podfolderów, skopiowanie do nich bibliotek DLL i ustawienie ich jako Zawsze kopiuj zawartość.

W ten sposób narzędzie do publikowania ClickOnce automatycznie dołącza te pliki i foldery do manifestu i wdraża wraz z nimi oprogramowanie

Tutaj jest naprawdę wiele odpowiedzi, ale moje jest proste i jasne, bez grania w GAC .

Problem polegał na tym, że plik wykonywalny potrzebuje kopii prawa SQLite.Interop.dll(x86 lub x64), aby uzyskać dostęp do naszej bazy danych.

Przeważnie architektury mają warstwy, aw moim przypadku Warstwa danych ma wymaganą bibliotekę DLL dla połączenia SQLite.

Więc po prostu umieściłem skrypt po kompilacji w moim rozwiązaniu warstwy danych i wszystko działało dobrze.

TL; DR;

1. Ustaw wszystkie projekty swojego rozwiązania na x86lub x64w opcjach kompilacji.

2. Dodaj następujące elementy Post-Build-Scriptdo projektu za pomocą SQLite nuget Package:

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

Oczywiście musisz zmienić skrypt Release Buildi x86kompilacje.

STL; DR;

Umieść swój SQLite.Interop.dllnastępny obok *.exepliku.

Domyślna instalacja wersji SQLite z wieloma architekturami (x86, x64) z NuGet wykazuje opisane zachowanie. Jeśli chcesz załadować poprawną wersję dla faktycznej architektury, którą środowisko uruchomieniowe .NET wybrało do uruchomienia aplikacji na twoim komputerze, możesz dać programowi ładującemu DLL wskazówkę, gdzie zlokalizować poprawną bibliotekę w następujący sposób:

Dodaj deklarację dla wywołania funkcji kernel32.dll do SetDLLDirectory () przed 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);

Następnie użyj własnej metody do określenia poprawnego podkatalogu, aby znaleźć wersję SQLite.Interop.dll specyficzną dla architektury. Używam następującego kodu:

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

nawet jeśli jest to stary post, chciałbym podzielić się rozwiązaniem, które tu znalazłem: http://system.data.sqlite.org/index.html/info/54e52d4c6f

Jeśli nie chcesz przeczytać całego problemu, rozwiązaniem jest skopiowanie pliku „msvcr100.dll” (który można znaleźć w katalogu Windows \ System32) w tej samej ścieżce, co SQLite.Interop.dll.

Radzę przeczytać problem, aby zrozumieć, dlaczego i włączyć plik do instalacji, ale aby zainstalować go tylko w przypadku wystąpienia błędu, uczyniłem go opcjonalnym składnikiem do wyboru w opcjach instalacji.

HTH, Formentz

Jak mówi wiki SQLite , wdrożenie aplikacji musi być:

Musisz więc przestrzegać zasad. Znajdź dll, który pasuje do Twojej platformy docelowej i umieść go w lokalizacji, opisuje na zdjęciu. Dll można znaleźć w YourSolution / packages / System.Data.SQLite.Core.% Version% /.

Miałem problemy z wdrażaniem aplikacji, więc właśnie dodałem SQLite.Interop.dll do mojego projektu, dodałem folder x86 do AppplicationFolder w projekcie instalacyjnym i dodałem odwołania do plików do dll.

Ten błąd można również uzyskać, jeśli próbujesz uruchomić 32-bitową bibliotekę DLL w 64-bitowym projekcie.

Dostałem to, gdy umieściłem ten sam plik (SQLite.Interop.dll w wersji 32-bitowej) zarówno w folderze x86, jak i x64.

Jeśli pobranie poprawnego binarny dla SQLiteskopiuj SQLite.Interop.dlldo swojego wydania lub Debug folderu zależności od opcji kompilacji projektu.

Nie wiem, dlaczego nie zostało to jeszcze uwzględnione, ale musiałem przeprowadzić badania i przekonać się o tym sam, więc mam nadzieję, że ktoś znajdzie tę odpowiedź i uratuje kłopoty. To było dla aplikacji WPF. Działa dobrze na moim Dev Dev Box, ale nie działało na komputerze, na którym go kopiowałem i otrzymałem Unable to load DLL 'SQLite.Interop.dll'błąd. Przeniesiłem wszystkie powiązane katalogi i pliki bezpośrednio z mojego folderu „Debuguj” na ten inny komputer, gdy dostałem ten sam błąd co OP, gdy go uruchomiłem. Mój folder „bin” zawierający moje biblioteki DLL został skopiowany do „Debug \ bin” i wszystkie zostały uwzględnione, wraz z plikami aplikacji podczas kopiowania na inny komputer przy użyciu tej ścieżki, więc nie brakowało żadnych plików.

Rzeczy, które widziałem, powiedział w innych odpowiedziach, które nie miały zastosowania:

• Nie korzystałem z pakietu NuGet ani nie musiałem tworzyć folderów x86 lub x64, które, jak się wydaje, tworzy pakiet NuGet. Moje biblioteki DLL (System.Data.SQLite i SQLite.Interop.dll, a także System.Data.SQLite.config) znajdują się w folderze „bin” w moim projekcie i zostały skopiowane ręcznie (utwórz folder „bin” w Eksploratorze rozwiązań w VS, wklej biblioteki DLL do tego folderu w Eksploratorze Windows, użyj polecenia Dodaj> Istniejący element, aby przenieść pliki do folderu / projektu VS). Następnie odwołuję się do nich jako Zespoły referencyjne w moim projekcie, używając tej lokalizacji („Referencje”> „Dodaj referencję”, i przejdź do jednej, przepłucz, powtórz dla reszty). Dzięki temu mój projekt dokładnie wie, gdzie się znajdują.
• Nie musiałem odwoływać się do żadnego pliku DLL SQLite w mojej app.config ani nawet dotykać mojego pliku MyProject.csproj.
• Nie musiałem nawet określać konkretnego procesora! Kompilacja mojego projektu jest przeznaczona na „Dowolny procesor”, mimo że mam tylko mieszane lub 64-bitowe biblioteki DLL i będę działać tylko w systemie Windows 7+, czyli 64-bitowych systemach operacyjnych. (brak tylko bibliotek x86 / 32-bitowych bibliotek DLL)
• Określiłem je już jako „Treść” i „Kopiuj, jeśli nowsze” dla tych bibliotek DLL, gdy wystąpił błąd OP.

Znalazłem to : https://system.data.sqlite.org/index.html/doc/trunk/www/faq.wiki#q20 :

(11) Dlaczego otrzymuję wyjątek DllNotFoundException (dla „sqlite3.dll” lub „SQLite.Interop.dll”) podczas próby uruchomienia mojej aplikacji?

Nie można zlokalizować nazwanej biblioteki linków dynamicznych (DLL) lub nie można jej załadować z powodu brakujących zależności. Upewnij się, że nazwana biblioteka linków dynamicznych znajduje się w katalogu aplikacji lub katalogu wzdłuż ŚCIEŻKI systemowej i spróbuj ponownie. Upewnij się także, że niezbędna redystrybucja środowiska wykonawczego Visual C ++ została zainstalowana, chyba że korzystasz z biblioteki linków dynamicznych, która została z nią połączona statycznie.

Podkreśl moją odważną część w akapicie. Komputer docelowy był świeży i nie załadowano żadnych programów oprócz .NET 4.0. Po zainstalowaniu C ++ był w stanie wykonać polecenia SQLite. To powinien był być jeden z pierwszych FAQ i część wymagań wstępnych, ale został pochowany na # 11. Mój komputer programistyczny już go załadował, ponieważ został dostarczony z Visual Studio, więc dlatego działał.

Pobierz:
Visual C ++ Redistributable for Visual Studio 2015:
https://www.microsoft.com/en-us/download/details.aspx?id=48145

Aktualizacja 3 (aktualizacja zbiorcza):
https://www.microsoft.com/en-us/download/details.aspx?id=53587

Zacząłem używać Costura.Fody do pakowania zestawów (.net) oraz osadzania i wstępnego ładowania natywnych bibliotek DLL. Pomaga to również później, z dystrybucją, ponieważ można wysłać jeden plik.

1. Zainstaluj Costura Fody z Nuget.

2. W swoim projekcie C # utwórz folder o nazwie costrua32. Tam dodaj wszystkie rodzime pliki dll, które C # załadować.

3. Po dodaniu ich do tego folderu. Kliknij okno właściwości i zmień akcję kompilacji na „Osadzony zasób”

4. Na koniec musisz zmienić plik XML o nazwie FodyWeavers.xml w następujący sposób. Tutaj określam najpierw załaduj dll sql. (pamiętaj, że upuściłeś .dll)

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

Zaletą tego jest to, że nie trzeba zapisywać żadnych zdarzeń przed kompilacją ani po kompilacji, a produkt końcowy jest całkowicie zamknięty w jednym większym pliku.

Dodałem również dll do projektu testowego (poprzez Nuget Manager) i naprawiłem to.

Miałem ten problem, ponieważ pakiet redystrybucyjny Visual C ++ 2010 nie został zainstalowany na moim komputerze. Jeśli jeszcze nie zainstalowałeś pakietu redystrybucyjnego Visual C ++ 2010 Pobierz i zainstaluj go (sprawdź bibliotekę x86 lub 64 dll).

Mam ten sam problem. Jednak w końcu mogę to naprawić. Obecnie używam Visual Studio 2013 Community Edition. Używam po prostu Add-> Existing Item ... i przeglądam, gdzie znajdują się pliki SQLite.Data.SQLite (w moim przypadku jest to „C: \ Program Files (x86) \ System.Data.SQLite \ 2013 \ bin”). Nie zapomnij zmienić rodzaju tego, co chcesz dołączyć do plików zespołu (* .dll; * .pdb) . Wybierz „ SQLite.Interop.dll ” w tym folderze. Odtąd mogę kontynuować bez żadnych problemów. Powodzenia wszystkim. ^ _ ^ PS Tworzę aplikację internetową. Nie próbowałem jeszcze w aplikacji okienkowej lub innych.

Przed kompilacją spróbuj ustawić docelową platformę na x86 lub x64 (a nie na dowolny procesor): Projekt-> Właściwości-> Kompilacja-> Cel platformy w Visual Studio.

Skopiuj SQLite.Interop.dll do katalogu projektu.

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

Zmagałem się z tym od dłuższego czasu i czasami okazało się, że ustawienie testowe jest nieprawidłowe. Zobacz ten obraz:

Po prostu odznaczam ustawienie testowe, a problem znika. W przeciwnym razie wystąpi wyjątek. Mam nadzieję, że to komuś pomoże. Nie jestem pewien, czy jest to podstawowa przyczyna.

Skopiuj pliki „SQLite.Interop.dll” dla folderów x86 i x64 w folderze debugowania. pliki te należy skopiować do folderów „x86” i „x64” w folderze debugowania.

Moja aplikacja jest aplikacją internetową (ASP.NET MVC) i musiałem zmienić pulę aplikacji do uruchomienia pod LocalSystemzamiast ApplicationPoolIdentity. Aby to zrobić:

1. Otwórz Menedżera IIS
2. Znajdź pulę aplikacji, w której działa Twoja witryna.
3. Kliknij Ustawienia zaawansowane w działaniach
4. Zmień tożsamość na LocalSystem

Nie mam pojęcia, dlaczego to rozwiązuje problem.

Nie wiem, czy to dobra odpowiedź, ale udało mi się rozwiązać ten problem, uruchamiając aplikację pod AppDomain z tożsamością „System lokalny”.

Pracuję nad prostą aplikacją konsoli, aby dodać dane testowe do bazy danych SQLite i otrzymywałem ten błąd. Konfiguracja projektu to „Dowolny procesor”. Naprawiłem to, kopiując SQLite.Interop.dll do folderu bin \ debug. Lepszym sposobem byłoby użycie metody @Wil, ale jak określić to dla konfiguracji „Any CPU”?

Czy może istnieć spór o zgromadzenie? Sprawdź, czy w bibliotece DLL jest inna aplikacja z blokadą plików.

Jeśli to jest powód, powinno być łatwo użyć narzędzia takiego jak Sysinternal's Process Explorer, aby odkryć program naruszający prawo.

HTH, Clay

Dla odniesienia dla każdego, kto patrzy na to pytanie:

Jeśli używasz pakietu nuget, instaluje on regułę kompilacji, która wykonuje kopiowanie za Ciebie. (zobacz w System.Data.SQLite.Core.1.0.94.0 \ build - lub jakiejkolwiek zainstalowanej wersji rdzenia).

Instalator nuget automatycznie dodaje regułę do pliku projektu.

To wciąż nie rozwiązuje problemu z przypadkiem testowym. Podejście DeploymentItem ( https://stackoverflow.com/a/24411049/89584 ) jest jedyną rzeczą, która wydaje się tam działać.

Natknąłem się na ten problem, w rozwiązaniu z projektem sieci WebAPI / MVC5 i projektem testu funkcji, które oba czerpały z tego samego projektu dostępu do danych (lub „Core”). Podobnie jak wielu innych użytkowników korzystam z kopii pobranej za pośrednictwem NuGet w Visual Studio 2013.

To, co zrobiłem, było w Visual Studio dodałem folder rozwiązania x86 i x64 do testu funkcji i projektów internetowych. Zrobiłem następnie Right Click | Add Existing Item...i dodałem odpowiednią bibliotekę SQLite.interop.dll ..\SolutionFolder\packages\System.Data.SQLite.Core.1.0.94.0\build\net451\[appropriate architecture]dla każdego z tych folderów. I wtedy zrobił Right Click | Propertiesi ustawić Copy to Output Directorysię Always Copy. Następnym razem, gdy musiałem przeprowadzić testy funkcji, testy zakończyły się powodzeniem.