Periodicamente, recebo a seguinte exceção:

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

Estou usando 1.0.82.0. , instalando-o com nuget no VS2010, OS Win7 64.

Quando a exceção começa a aparecer, ela aparece constantemente - na depuração e liberação e execução do aplicativo dentro ou fora do VS.

A única maneira de pará-lo é logoff e logon. A exceção não é lançada e a dll é carregada. Pode funcionar por dias, mas depois pode quebrar novamente.

Alguém viu algo assim e existe uma solução para isso?

Sei que estou atrasado para a festa, mas tive esse problema logo depois de baixar o x86 / x64 mais recente de hoje (versão 1.0.88.0). Meu IIS local no VS2012 executa 32 bits por padrão e não há uma maneira fácil de mudar para x64. Meu servidor de produção executa 64 bits.

Enfim, instalei o pacote NuGet em um projeto DLL e recebi esse erro. O que eu tinha que fazer para fazê-lo funcionar também tinha que instalá-lo no projeto do site principal . Mesmo que não toque nas classes SQLite.

Meu palpite é que o SQLite usa o assembly de entrada para detectar qual versão do Interop carregar.

Eu tive esse problema porque uma dll que eu estava usando tinha o Sqlite como uma dependência (configurada no NuGet com apenas o pacote principal do Sqlite.). O projeto compila e copia todas as DLLs do Sqlite, exceto o 'SQLite.Interop.dll' (pasta x86 e x64).

A solução foi muito simples: basta adicionar o pacote Sqlite.Core como uma dependência (com o NuGet) ao projeto que você está construindo / executando e as dll-s serão copiadas.

Eu tive esse mesmo problema ao usar o SQLite em um projeto WPF cujo destino da plataforma era Any CPU. Corrigi-o seguindo as seguintes etapas:

1. Abra o designer do projeto no Visual Studio. Detalhes sobre como fazer isso podem ser encontrados aqui .
2. Clique na guia Build.
3. Desabilite a prefer 32-bitopção.

Como alternativa, você pode definir o destino da plataforma como x86ou x64. Acho que esse problema é causado pela System.Data.SQLitebiblioteca que usa o destino da plataforma para obter a localização do arquivo 'SQLite.Interop.dll'.

ATUALIZAR:

Caso o designer do projeto não possa ser alcançado, basta abrir o *.csprojarquivo project ( ) em um editor de texto e adicionar o valor <Prefer32Bit>false</Prefer32Bit>à <PropertyGroup>...</PropertyGroup>tag.

Código de exemplo

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

Foi assim que eu o consertei no meu projeto.

Estava funcionando e, quando um colega enviou suas alterações, recebi a exceção "Não foi possível carregar a DLL 'SQLite.Interop.dll'".

Diferindo do arquivo .csproj do projeto, ele estava na versão NÃO-TRABALHANDO:

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

E é isso que a versão WORKING tinha:

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

Depois de voltar, não recebi a exceção. Os arquivos DLL foram despejados nas pastas apropriadas Debug \ x64 (etc).

Portanto, depois de adicionar o NuGet, a implantação não copia as Interops. Você pode adicionar isso ao seu arquivo csproj e deve corrigir esse comportamento:

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

Se você procurar o NuGet for SQLite na fonte, poderá ver o que eles estão fazendo especificamente. Isso me permitiu obter uma implantação trabalhando com o ASP.Net Core.

Quando você entrar nesse estado, tente executar um Rebuild-All. Se isso resolver o problema, você pode ter o mesmo problema que eu tive.

Alguns antecedentes (meu entendimento) :

• O SQLite possui 1 assembly gerenciado (System.Data.SQLite.dll) e vários assemblies específicos da plataforma (SQLite.Interop.dll). Ao instalar o SQLite com Nuget, o Nuget adicionará os assemblies específicos da plataforma ao seu projeto (em várias pastas: \ x86, \ x64) e configura essas DLLs para "Copiar sempre".

• Após o carregamento, o assembly gerenciado procurará por assemblies específicos da plataforma nas pastas \ x86 e \ x64. Você pode ver mais sobre isso aqui . A exceção é esse assembly gerenciado tentando encontrar o relevante (SQLite.Interop.dll) dentro dessas pastas (e com falha).

Meu cenário :

Eu tenho 2 projetos na minha solução; um aplicativo WPF e uma biblioteca de classes. O aplicativo WPF faz referência à biblioteca de classes, e a biblioteca de classes faz referência ao SQLite (instalado via Nuget).

O problema para mim foi quando eu modifico apenas o aplicativo WPF, o VS tenta fazer uma reconstrução parcial (percebendo que a dll dependente não foi alterada). Em algum lugar desse processo, o VS limpa o conteúdo das pastas \ x86 e \ x64 (eliminando o SQLite.Interop.dll). Quando eu faço um Rebuild-All completo, o VS copia as pastas e seu conteúdo corretamente.

Minha solução :

Para corrigir isso, acabei adicionando um processo Pós-Compilação usando o xcopy para forçar a cópia das pastas \ x86 e \ x64 da biblioteca de classes para o meu diretório WPF project \ bin.

Como alternativa, você pode fazer coisas mais sofisticadas com os diretórios de configuração / saída da compilação.

Eu tive o mesmo problema ao executar o Visual Studio Express 2013. Tentei várias soluções mencionadas aqui e em outros lugares sem sucesso. Espero que essa correção ajude outras pessoas.

Corrigi-o usando o DeploymentItematributo na minha classe de teste que testa o serviço baseado em SQLite.

Exemplo:

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

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

Isso faz com que o necessário SQLite.Interop.dllseja copiado para o x86diretório na pasta "TestResults" apropriada.

Tudo é verde. Tudo está bem.

Atualizar o NuGet Tools -> Extension and updatese reinstalar o SQLite.Core com o comando PM> Update-Package -reinstall System.Data.SQLite.Corecorrigiu isso para mim.

Eu tive um problema semelhante em uma solução de vários projetos. O SQLite.Interop.dll era necessário para um dos plugins distribuídos com o software usando o ClickOnce.

Quanto à depuração no visual studio, tudo funcionou bem, mas a versão implantada estava ausente nas pastas x86 / e x64 / que continham essa DLL.

A solução para fazê-lo funcionar após a implantação usando o ClickOnce foi criar no projeto de inicialização da solução (também a que está sendo publicada) essas duas subpastas, copiar nelas as DLLs e defini-las como Content Copy Always.

Dessa forma, a ferramenta de publicação ClickOnce inclui automaticamente esses arquivos e pastas no manifesto e implanta o software com eles

Há realmente muitas respostas aqui, mas as minhas são simples e claras, sem brincadeiras no GAC .

O problema era que o arquivo executável precisa de uma cópia do direito SQLite.Interop.dll(x86 ou x64) para acessar nosso banco de dados.

As arquiteturas têm principalmente camadas e, no meu caso, a camada de dados possui a DLL necessária para a conexão SQLite.

Então, eu simplesmente coloquei um script de pós-compilação na minha solução de camada de dados e tudo funcionou bem.

TL; DR;

1. Defina todos os projetos da sua solução para x86ou x64nas opções de compilação.

2. Adicione o seguinte Post-Build-Scriptao projeto com o SQLite nuget Package:

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

Claro que você precisa alterar o script Release Builde criar x86.

STL; DR;

Coloque o seu SQLite.Interop.dllpróximo ao *.exearquivo.

A instalação padrão da versão multi-arquitetura (x86, x64) do SQLite do NuGet exibe o comportamento que você descreveu. Se você deseja carregar a versão correta para a arquitetura real escolhida pelo tempo de execução do .NET para executar seu aplicativo em sua máquina, pode dar ao carregador DLL uma dica sobre onde localizar a biblioteca correta da seguinte maneira:

Adicione uma declaração para a chamada de função kernel32.dll ao SetDLLDirectory () antes do seu 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);

Em seguida, use seu próprio método para determinar o subdiretório correto e encontrar a versão específica da arquitetura do 'SQLite.Interop.dll'. Eu uso o seguinte código:

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

mesmo que seja um post antigo, gostaria de compartilhar a solução que encontrei aqui: http://system.data.sqlite.org/index.html/info/54e52d4c6f

Se você não quiser ler todo o problema, a solução é copiar o arquivo "msvcr100.dll" (que pode ser encontrado no diretório Windows \ System32) no mesmo caminho que o SQLite.Interop.dll.

Eu aconselho a ler o problema para entender o porquê e incluir o arquivo na sua instalação, mas para instalá-lo apenas se o erro ocorrer, o tornei um componente opcional selecionável nas opções de instalação.

HTH, Formentz

Como o wiki do SQLite diz, a implantação do seu aplicativo deve ser:

Então você precisa seguir as regras. Encontre DLL que corresponde à sua plataforma de destino e colocá-lo no local, descrito na figura. Dlls podem ser encontradas em YourSolution / packages / System.Data.SQLite.Core.% Version% /.

Eu tive problemas com a implantação do aplicativo, então acabei de adicionar o SQLite.Interop.dll correto ao meu projeto, a pasta x86 adicionada ao AppplicationFolder no projeto de instalação e as referências de arquivo adicionadas à dll.

Você também pode receber esse erro se estiver tentando executar uma dll de 32 bits, em um projeto de 64 bits.

Eu obtive isso quando coloquei o mesmo arquivo (SQLite.Interop.dll na versão de 32 bits) nas pastas x86 e x64.

Se você baixar o binário correto para SQLitecopiar SQLite.Interop.dllna pasta Release ou Debug, de acordo com a opção de criação do projeto.

Ainda não sei por que isso ainda não foi incluído, mas tive que fazer a pesquisa e descobrir isso sozinho, por isso espero que alguém encontre essa resposta e seja salvo do problema. Isso foi para um aplicativo WPF. Funcionou bem na minha caixa de desenvolvimento, mas não funcionou no computador em que eu estava copiando e recebi o Unable to load DLL 'SQLite.Interop.dll'erro. Eu movi todos os diretórios e arquivos associados, diretamente da minha pasta "Debug" para outro computador quando recebi o mesmo erro do OP quando o executei. Minha pasta "bin" que continha minhas DLLs foi copiada para "Debug \ bin" e todas foram incluídas, junto com meus arquivos de aplicativo, quando eu copiei para o outro computador usando esse caminho, para que não houvesse nenhum arquivo ausente.

O que vi foi dito em outras respostas que não se aplicavam:

• Eu não usei o pacote NuGet ou preciso criar pastas x86 ou x64 que parece que o pacote NuGet cria. Minhas DLLs (System.Data.SQLite e SQLite.Interop.dll, juntamente com System.Data.SQLite.config) estão na pasta "bin" do meu projeto e foram copiadas manualmente (crie a pasta "bin" no Gerenciador de Soluções em VS, cole DLLs nesta pasta no Windows Explorer, use Adicionar> Item Existente para trazer arquivos para a pasta / projeto do VS). Em seguida, eu os refiro como Assemblies Referenciados no meu projeto usando esse local ("Referências"> "Adicionar Referência" e navegue até um, enxágue e repita o restante). Isso garante que meu projeto saiba exatamente onde eles estão.
• Não precisei fazer referência a nenhum arquivo DLL SQLite no meu app.config ou sequer tocar no meu arquivo MyProject.csproj.
• Eu nem precisava especificar um processador específico! A compilação do meu projeto é para "Qualquer CPU", mesmo que eu tenha apenas DLLs mistas ou de 64 bits e esteja executando apenas no Windows 7+, que são sistemas operacionais de 64 bits. (sem DLLs somente para x86 / 32 bits)
• Eu já estava especificando-os como "Conteúdo" e "copie se for mais recente" para essas DLLs quando tive o erro do OP.

O que eu encontrei foi isso, em https://system.data.sqlite.org/index.html/doc/trunk/www/faq.wiki#q20 :

(11) Por que obtenho uma DllNotFoundException (para "sqlite3.dll" ou "SQLite.Interop.dll") ao tentar executar meu aplicativo?

A biblioteca de vínculo dinâmico (DLL) nomeada não pode ser localizada ou não pode ser carregada devido à falta de dependências. Verifique se a biblioteca de vínculo dinâmico nomeada está localizada no diretório do aplicativo ou em um diretório ao longo do PATH do sistema e tente novamente. Além disso, verifique se o tempo de execução necessário do Visual C ++ redistribuível foi instalado, a menos que você esteja usando uma biblioteca de vínculo dinâmico que foi criada estaticamente vinculada a ele.

Ênfase minha nessa parte em negrito dentro do parágrafo. O computador de destino estava atualizado e não tinha programas carregados, exceto o .NET 4.0. Depois de instalar o C ++, ele foi capaz de concluir os comandos para o SQLite. Essa deveria ter sido uma das primeiras perguntas frequentes e parte dos pré-requisitos, mas foi enterrada na 11ª posição. Meu computador de desenvolvimento já o carregou porque veio com o Visual Studio; é por isso que funcionou.

Download:
Visual C ++ redistribuível para Visual Studio 2015:
https://www.microsoft.com/en-us/download/details.aspx?id=48145

Atualização 3 (atualização cumulativa):
https://www.microsoft.com/en-us/download/details.aspx?id=53587

Comecei a usar o Costura.Fody para empacotar (.net) assemblies e incorporar e pré-carregar dlls nativas. Isso também ajuda mais tarde, com a distribuição, pois você pode enviar um arquivo.

1. Instale o Costura Fody do Nuget.

2. No seu projeto C #, crie uma pasta chamada costrua32. Lá, adicione quaisquer dlls nativas que C # carregar.

3. Depois de adicioná-los a esta pasta. Clique na janela de propriedades e altere a ação de compilação para "Recurso incorporado"

4. Finalmente, você precisa alterar o arquivo XML chamado FodyWeavers.xml da seguinte maneira. Aqui estou especificando carregar a dll sql primeiro. (observe que você solta o arquivo .dll)

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

A vantagem disso é que você não precisa gravar nenhum evento de pré ou pós-construção, e o produto final é totalmente encapsulado em um arquivo maior.

Também adicionou a dll ao projeto de teste (por meio do Nuget Manager) e a corrigiu.

Eu tive esse problema porque o Visual C ++ 2010 redistribuível não está instalado no meu PC.se você ainda não instalou o Visual c ++ 2010 redistribuível Baixe e instale isso (verifique x86 ou 64 dll).

Eu tenho o mesmo problema. No entanto, finalmente, eu posso consertar. Atualmente, eu uso o Visual Studio 2013 Community Edition. Eu apenas uso Adicionar-> Item Existente ... e navegue até onde os arquivos SQLite.Data.SQLite estão (meu caso é 'C: \ Arquivos de Programas (x86) \ System.Data.SQLite \ 2013 \ bin'). Não se esqueça de alterar o tipo do que você incluirá em Arquivos de montagem (* .dll; * .pdb) . Escolha ' SQLite.Interop.dll ' nessa pasta. De lá em diante, posso continuar sem problemas. Boa sorte a todos vocês. ^ _ ^ PS Eu crio um aplicativo de formulário da web. Ainda não tentei no aplicativo de formulário de janela ou em outros.

Tente definir o destino da plataforma para x86 ou x64 (e não para qualquer CPU) antes de criar: Projeto-> Propriedades-> Compilar-> Destino da plataforma no Visual Studio.

Copie SQLite.Interop.dll no diretório do projeto.

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

Eu luto com isso há muito tempo e, ocasionalmente, descobri que a configuração do teste está incorreta. Veja esta imagem:

Acabei de desmarcar a configuração de teste e o problema desaparece. Caso contrário, a exceção ocorrerá. Felizmente, isso ajudará alguém. Não tenho certeza se é a causa raiz.

Copie os arquivos "SQLite.Interop.dll" para x86 e x64 na pasta de depuração. esses arquivos devem copiar para as pastas "x86" e "x64 na pasta de depuração.

Meu aplicativo é um aplicativo Web (ASP.NET MVC) e tive que alterar o pool de aplicativos para executar em LocalSystemvez de ApplicationPoolIdentity. Para fazer isso:

1. Abra o Gerenciador do IIS
2. Encontre o pool de aplicativos em que seu site está sendo executado.
3. Clique em Configurações avançadas nas ações
4. Alterar identidade para LocalSystem

Não faço ideia por que isso resolve o problema.

Não sei se é uma boa resposta, mas consegui resolver esse problema executando meu aplicativo em um AppDomain com uma identidade de "Sistema Local".

Estou trabalhando em um aplicativo de console simples para adicionar alguns dados de teste a um banco de dados SQLite e estava recebendo esse erro. A configuração do projeto é "Qualquer CPU". Corrigi-o, copiando o SQLite.Interop.dll para a pasta bin \ debug. Uma maneira melhor seria usar o método do @Wil, mas como você o especifica para a configuração "Qualquer CPU"?

Poderia haver contenção para a montagem? Verifique se há outro aplicativo com um bloqueio de arquivo na DLL.

Se esse for o motivo, deve ser fácil usar uma ferramenta como o Process Explorer do Sysinternal para descobrir o programa incorreto.

HTH, Clay

Para referência para quem olha para esta pergunta:

Se você usar o pacote nuget, ele instalará uma regra de compilação que fará a cópia para você. (consulte System.Data.SQLite.Core.1.0.94.0 \ build - ou qualquer versão do Core que você instalar).

O instalador do nuget adiciona a regra ao seu arquivo de projeto automaticamente.

Isso ainda não resolve o problema do caso de teste. A abordagem DeploymentItem ( https://stackoverflow.com/a/24411049/89584 ) é a única coisa que parece funcionar lá.

Eu deparei com esse problema, em uma solução com um projeto da Web WebAPI / MVC5 e um projeto de Teste de recursos, que ambos criaram o mesmo projeto de acesso a dados (ou 'Core'). Eu, como tantos outros aqui, estou usando uma cópia baixada via NuGet no Visual Studio 2013.

O que eu fiz foi no Visual Studio adicionar uma pasta de solução x86 e x64 aos Testes de Recursos e Projetos da Web. Em seguida, fiz um Right Click | Add Existing Item...e adicionei a biblioteca SQLite.interop.dll apropriada ..\SolutionFolder\packages\System.Data.SQLite.Core.1.0.94.0\build\net451\[appropriate architecture]para cada uma dessas pastas. Eu então fiz um Right Click | Propertiese ajustei Copy to Output Directorypara Always Copy. Na próxima vez que eu precisei executar meus testes de recursos, os testes foram executados com êxito.