Não foi possível carregar a DLL 'SQLite.Interop.dll'

205

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?

xll
fonte
2
Sim, está definido para copiar sempre. Eu tenho pastas x64 e x86 na lixeira / depuração. E funciona principalmente, mas às vezes apenas para para trabalhar. Provavelmente algo está bloqueando o acesso à dll, vou tentar descobrir na próxima vez que parar de funcionar. Como eu disse, pode funcionar dias sem problemas.
XLL
13
Recebi esse erro imediatamente após adicionar o pacote de nuget SQLite a um novo projeto de console. A cópia manual do SQLite.Interop.dll da pasta x86 em um nível superior permite que o aplicativo seja executado. Parece estranho para mim que isso seria tão quebrado.
lesscode
@ Wayne Sim, isso definitivamente ajuda. Mas, no meu caso, estamos trabalhando juntos no projeto, e meu amigo está usando o x86, enquanto eu x64. E como eu notei, às vezes para de funcionar. Embora isso não tenha acontecido comigo no mês passado.
xll 22/12/12
1
Se você baixar o binário correto para o SQLite, copie o SQLite.Interop.dll para a pasta Release ou Debug, de acordo com a opção de compilação do projeto.
Elshan
Este é um erro aleatório ... às vezes ocorre e às vezes não ocorre no meu projeto. Tentei de tudo.
BK

Respostas:

141

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.

Kugel
fonte
11
Funcionou para mim depois que adicionei a referência ao SQLite Core com NuGet no projeto principal.
Luca Cremonesi
Adicionando sqllite.core ao projeto principal trabalhou para mim em minha solução WPF
Dipu Raj
Eu tive que fazer as duas coisas instalar-package Sqlite, bem como Install-Package System.Data.SQLite.Core em meu website, embora as chamadas db estão em uma biblioteca ...
Essa deve ser a resposta.
Bobby Turkalino 03/07
4
O que você quer dizer com projeto "site principal"? No meu caso, estou trabalhando na área de trabalho. Você quer dizer o projeto "startup"?
UUDdLrLrSs
60

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.

Marin
fonte
Trabalhou para mim! Graças
Tristan Djahel
Acordado. Estou usando o pacote 'Sqlite.Net PCL', mas descobri que também precisava do 'System.Data.SQLite Core (x86 / x64)'. Eu também tive que mudar o (s) projeto (s) que o referenciavam para usar um destino de plataforma 'x86' ou 'x64', em vez de 'Qualquer CPU'.
Andrew Stephens
2
Tentei algumas soluções postadas aqui, esta realmente funcionou melhor.
Batman
2
Como você pode adicionar uma dependência como essa? nunca fiz isso (VS2013)
jpgrassi
3
Vá para Ferramentas -> Gerenciador de Pacotes NuGet -> Gerenciar pacotes NuGet para a solução ... -> Online -> Todos. Em seguida, pesquise sqlite e adicione System.Data.SQLite Core (x86 / x64).
Marin
44

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>
Caleb Kiage
fonte
Estou usando o VS 2010, não existe essa opção.
XLL
@ xll, editei a resposta para esclarecimentos. Verifique se a edição esclarece as coisas.
precisa saber é o seguinte
10
No VS2012, essa opção está acinzentada para mim.
Kugel
6
A opção está ativada apenas em projetos EXE, mas acho que a maioria de nós tem esse problema nos projetos de teste de unidade.
Brannon
1
Foi acinzentado para mim em um projeto WPF no VS Pro 2015. o .csprojarquivo já estava definido como false, mas ainda tinha o erro.
vapcguy
32

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

Wil
fonte
<itemgroup> para "SQLite.Interop.dll" não existe no arquivo .csproj do projeto. Ainda tentei adicionar sua solução, mas não funcionou :(
ayc
Isso não funcionará no VS2012, os elementos não existem.
Htm11h 27/08/2015
Muito obrigado. Funciona em 2015 vs.
Jevgenij Kononov
29

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.

b.pell
fonte
10
ContentSQLiteInteropFiles é a resposta. A maioria das respostas principais é adivinhação.
Corey Alix
6
Sim, ContentSQLiteInteropFiles é a resposta. 1. Essa deve ser a resposta aceita 2. Por outro lado, deve-se investigar que, como um pacote de pepitas, como fazer isso funcionar automaticamente, ou pelo menos documentar a necessidade dessa configuração.
Gerleim 03/05/19
Deve ser a resposta aceita. Super simples. 1. descarregue o projeto 2. adicione o item acima ao csproj 3. recarregue o projeto. é tão fácil ...
BillRuhl
24

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.

sfm
fonte
1
A mensagem que recebi dizia que esses arquivos estavam ausentes, mas achei que era um problema de permissão. Depois que vi sua mensagem, percebi que elas nunca chegaram ao servidor quando implantei.
Stradas
1
Minha solução quase idêntica foi adicionar pastas x86 e x64 ao meu projeto de inicialização e adicionar os arquivos de interoperabilidade x86 e x64 nas respectivas pastas. Defino a opção dos arquivos como "conteúdo" e "compilação sempre". Essa é a única maneira de conseguir que meu aplicativo Windows Forms se conecte a um arquivo de banco de dados s3db incorporado quando implantei o aplicativo com o ClickOnce em outros PCs. Frustrantemente, não tive um erro SQLite quando desenvolvi e testei o aplicativo no meu PC.
David Alan Condit
Ainda está acontecendo com o VS 2017: '(
wmebane
1
Essa é a resposta que me ajuda a entender meu problema, embora minha correção seja um pouco diferente. Meu problema é que eu adicionei o system.data.Sqlite.dll manualmente. Dessa maneira, o Sqlite.Interop.dll não é automaticamente copiado para \ x86 e x64. A correção é excluir a referência e adicioná-la pelo Nuget.
Susan Wang
19

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.

Michael Bromley
fonte
1
Esta solução funciona apenas se você estiver usando o namespace Microsoft.VisualStudio.TestTools.UnitTesting
sapbucket
4
Esta é uma solução correta se você estiver usando o MSTest. O SQLite funcionou bem, encontrando o SQLite.Interop.dll sem problemas, até que eu usei DeploymentItem ("some.csv") para um teste. A inclusão do arquivo .csv dessa maneira acionou o MSTest para copiar todas as dlls referenciadas para o diretório TestResults. Como o SQLite.Interop.dll não é mencionado no projeto (e não pode ser porque é um código não gerenciado), ele nunca foi copiado.
Johann
Sua melhor aposta é adicionar duas linhas, uma para cada arquitetura. Isso protege você no caso de o executor de teste estar executando 64 bits.
precisa
13

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.

Filippo Vigani
fonte
Se você receber um erro ao fazer isso, removendo meus DLLs SQLite / referências e completamente reinstalá-los a partir de NuGet fez o truque para mim
KayakinKoder
reinstalar o sqllite core ajuda para mim também. Ocorreu no VS2012. VS não incluem x62 versão de pacote de deploy web
Andrey R
Corrigido para mim também no VS2015 Professional.
Rahul Kishore
9

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

user1892410
fonte
1
essa foi a única solução que funcionou para mim ... e garoto .. foi difícil depurar quando o aplicativo é fechado no PC do usuário.
estóico
8

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.

Smartis
fonte
6

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));
Kevin Smathers
fonte
4

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

Formentz
fonte
Agradecemos muito por isso, eu tentei tudo e esta foi a solução
David Benko
4

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

Implantação de aplicativo

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.

Keltar Helviett
fonte
3

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.

Morten Holmgaard
fonte
3

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.

Elshan
fonte
3

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

vapcguy
fonte
3

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.

Screig
fonte
Nome da pasta deve ser costura32, documentação github.com/Fody/Costura#native-libraries-and-preloadorder
Elton Saunders
3

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

Antonin GAVREL
fonte
2

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

Ali Yousefi
fonte
Sim. Este também foi o meu caso ... apenas o meu exigia o SP1 redistribuível do Visual C ++ 2010. A melhor alma é ler com atenção qual tempo de execução é necessário para sua versão. Por exemplo, aqui: system.data.sqlite.org/index.html/doc/trunk/www/downloads.wiki
Velja Radenkovic
2

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.

Kayun Chan
fonte
2

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.

thardes2
fonte
2

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
Ahmad Aghazadeh
fonte
Eu tive que dar permissões IIS_APPPOOL Edit para o arquivo Bin para resolver o problema. Apenas copiando o ddl estava causando um acesso negado ao dll
Alexanderd
A adição desses arquivos resolveu os problemas, mas esta é uma solução temporária.
Kartik Goyal
2

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

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.

Tony Sun
fonte
1
Embora esse link possa responder à pergunta, é melhor incluir aqui as partes essenciais da resposta e fornecer o link para referência. As respostas somente para links podem se tornar inválidas se a página vinculada for alterada. - Do comentário
Robert Columbia
No meu caso, o arquivo testsettings está errado: <TestSettings ... <Deployment> <DeploymentItem filename = "bin \ Relase \ a.test.dll". o local do arquivo está configurado incorretamente.
Tony Sun
2

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.

lágrima
fonte
2

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.

CodificaçãoYoshi
fonte
1

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

Jesse McDowell
fonte
1

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

pwrgreg007
fonte
1

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

Clay Compton
fonte
1

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

Malcolm
fonte
1

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.

Andrew Gray
fonte