We Keep Coding

System.Data.SQLite.dll - System.IO.FileNotFoundException

I use SQLite and works fine on the developer machine (or machine with Visual Studio).
But it does not work on PCs without VS. I "installed" the SQLite manually (32 bit version, added to the references, Copy Local: True). I get "System.IO.FileNotFoundException" System.Data.SQLite.dll exception.
The System.Data.SQLite.dll is in the output folder.
But I can not get it to work only if I install the SQLite with this: https://system.data.sqlite.org/downloads/1.0.105.2/sqlite-netFx46-setup-bundle-x86-2015-1.0.105.2.exe
Dev PC: x64 Win 10, application: x86 only
Please let me know if you need any other information.

Check which dependencies has your executable file (and, maybe, System.Data.SQLite.dll) with Dependency Walker or similar program. Then put these libraries you found into executable's folder one by one, until your executable will work.

You need to make sure the 64 bit C++ runtime DLLs are getting installed. They'll often be on the developer's system but not as often installed by your installer on the target system. Even though this is a .NET assembly, it appears to have C++ underpinnings.

How do I get the proper SQLite assemblies for a project configured for x86 CPU?

Background:
Working in C# using the 2.0 framework and setting up an application to use sqlite. When deployed to certain customer machines I get:
Could not load file or assembly System.Data.SQLite.dll
I am under the impression that there should be no client install of SQLite as long as you've placed the above DLL in the runtime directory. I have tried multiple configurations (x86 DLL compiled into a project targeting x86 cpu - failed on both x86 machines and x64 machines | x64 DLL compiled into a project targeting x64 CPU - failed on both x86 machines and x64 machines | both architecture versions of the DLL targeting Any CPU - failed on both x64 and x86).
I am using SQLite version 1.0.98.0. I'm not sure what relevant code I could post as this is an issue with a DLL reference, but I am happy to upload anything needed to foster a reasonable answer. I have no client computer cpu in mind so if I could get this running as x86 targeting x86 CPU that would be great. Any yes, I have already tried that combination using the correct DLL while making sure it ends up in the runtime folder and it still fails. If I could post more than two screen caps I would show the file as well, but alas I cannot.
I have been searching for quite a while and cannot seem to find an example that exactly fits what I want to do. The question has been asked but not solved. I read that the configuration of the DLL is what causes this and that is why I tried both DLL's targeting both processors. Seeing that this question is asked a lot and I still couldn't find my answer I have to assume a lot of people are in the same position as me so maybe we can work this one out together and give the community a great post on solving this issue.
Assembly information for the x86 configuration
Configuration Manager for x86 CPU

Make sure your dll are deployed properly on target machine. Some time setup compiler (Inno Setup) puts all the files in directory structure in same root folder hence .net can not file dll for expected path and hence it throws file not found exception

DLL Errors in 32 bits machine. Program made in C#

I did a program in C# which runs perfectly in my machine and in another one, of 64 bits, which have the .NET Framework.
When I try to run the program in a 32 bits machine It explodes and I get:
In this link (http://geekswithblogs.net/steveclements/archive/2008/04/30/error--eventtype-clr20r3.aspx) I found some solutions, but none worked for me. I already deleted the not used DLL, in particular those involving MySQL.
Do you have any suggestions?
Thank you.

This question requires more error details like exception information, VS version, What kind of exe (Winforms, WPF, etc), but you can start by answering the following questions:
- Is your exe built for anyCPU?
Is the same .net framework version installed on both 64-bit and 32-bit PC?
Are you having any code that uses 64-bit dll?
Are you having any code that uses 64-bit constructs? (checking pointer size)
What VS/.net framework/OS version does your developer PC has? The 32-bit PC?

Why might I get a DLL not found exception on Vista but not XP?

I have an app that relies on several managed libraries. These managed libraries in turn rely on some unmanaged libraries.
When I deploy the app to a machine running XP, it runs fine. When I do the same on a machine running Vista, I get a DLL not found exception.
I've tried both a VS2010 setup project and an NSIS installer to do the deployment and it's the same in both cases.
Why might this happen? What can I do to get around it?
Update - Further details
Both installers check for the installation of .NET 4.0 and install it if need be
The Vista computer is 64 bit, but the installation gets directed to the x86 program files folder as expected
In both cases I have an admin account
The DLLs are kept in the same directory as the executable
As far as I can tell, the files are getting copied to the right directory
Update 2
The full error is at http://pastebin.ca/2046487
The DLL is Audiere.Net.dll, which is one of mine and is a managed library.
I'm not sure if that error means that it can't find Audiere.Net.dll, or whether it can't load it because one of it's dependencies can't be found.
Update 3 - Stuff from Process Monitor
After running process monitor (thanks Mehrdad!) there are several entries which don't have a status of "SUCCESS". Some of these are "NAME NOT FOUND" and some are "PATH NOT FOUND". (It's even querying the PDB files, which I had thought were only used by a debugger.) It's really hard to see which entries might be the one leading to the actual failure. Anyway, I've uploaded the log (filtered to have a relevant path) in case it means something to anyone.
Update 4 - Added .pdb files
So I kinda got desperate and included the .pdb files to the output of the installer. I thought it would be useless, but it actually resulted in a more useful error. Rather than simply saying DLL not found, I now get a BadImageFormatException. Googling this tells me that this is a common problem for binaries compiled on x86 but being run on x64 (as the Vista machine is).
The suggested remedy is to force it to target x86, but Audiere.Net.dll already was. Could the fault lie with the library that it wraps?

Maybe there's some sort of redirection that's not actually letting your app install in the intended folder?
We'd need a bit more detail, but are you installing for the user or the machine? Are you an admin? Where is the DLL normally located?
Edit: Try using Process Monitor to monitor what file is actually being accessed.

If you are running a .Net application, do both computers have the proper Framework installed?

You mention that Audiere.Net.dll is targeted at x86, but what about your executable?
You can obviously recompile your program or use Corflags (part of the framework) to view the current setting on your exe.
Corflags ssd2.exe
Or to set or unset the flag
Corflags ssd2.exe /32BIT+
Corflags ssd2.exe /32BIT-
(Note, if your app is signed with a strong name it won't work unless you use /Force to remove the signature)

The solution turned out to be quite straightforward: one of the unmanaged DLLs needed to be recompiled for x64.
Key steps:
Check process monitor for likely sources of error. Look carefully at the error report that Windows offers to send when the app crashes.
Include the .pdb files for managed libraries. This seemed to result in more informative error messages.
These error messages not only specified which managed library was causing the error, but also indicated that it was a x86/x64 issue. (BadImageFormatException)
Following some sound advice, check that all of the unmanaged libraries are targeting x86. (Mine were, but it's good to be sure.)
Recompile the unmanaged dependencies of the troublesome managed library on an x64 machine.
Write an install script that copies the appropriate (x86 or x64) version of the DLL.
Profit!
Specifics:
The problem I had seemed to be with Audiere.Net.dll, but was actually caused by a problem with libaudieresharpglue.dll.
I use NSIS for installers. To accomplish the architecture specific DLL, I used a header called x64.nsh.

Usual reason is that the dll in question depends on other dlls which are not on the Vista machine (or possibly there but not registered.)

We ran into something simlar and found we needed to download the c++ Redistibuatable Package to get the program to run on windows 7 using 3rd party dlls.

I recall running into a similar issue with SQLite wrapper.
The source of the problem is the 32/64 bit issue of course, and it's the same scenario as the SQLite wrapper is a managed wrapper which makes it processor dependent.
I am guessing that while you're managed lib (Audiere.Net.dll) is compiled for 32 bits, you main application (ssd2.exe) is not.
The installation folder is determined by the configuration of the setup, but if the application project is not strictly configured to compile as a x86 project (usually targeting the default Any Cpu environment) then the application will launch as a 64 bit process, regardless of the installation path. This can be easily verified by looking at the process in task manager on a 64 bit machine, all 32 bit processes have an additional *32 on a 64 bit windows machine (they won't have it on a 32 bit machine).
EDIT: or more easily by looking at the project properties->Build-> Platform Target :)
Anyhow - you should change the project settings for the project that builds ssd2.exe to target x86 and you should be ok.

ClickOnce: BadImageFormatException when running x86 package on 64 bit windows

My .NET 2.0 application imports unmanaged 32 bit dll.
The dll is loaded (first interop call happens) when user opens a file via a dialog within the application.
When I deploy the application via clickonce with target platform "Any", users on 64 bit windows get BadImageFormatException when trying to open files from the application (at the moment the unmanaged dll is loaded). I understand this is due to incompabible bitness of the 64 bit process and the 32 bit unmanaged dll.
I have redeployed the application using x86 as target platform. As I understand it, this should solve the bitness problem.
BUT
When I run the deployed application built for x86 on 64 bit system, I now get BadImageFormatException immediately before the application even starts. Tested on at least three 64 bit machines. On 32 bit machines, it works with no problem.
When I run the application directly from VS (or not directly, just a normal build, not going via ClickOnce), there is no problem on 64 bit windows when using x86 target platform. The application starts and user can load file - the interop call succeeds.
I have been debugging this for 2 days straight with no result - I have tried on different computers. It seems to consistentnly work on one of the computers I have tried. However, I do not have permanent access to this computer.
I have managed to build the ClickOnce deployment on my computer once and it worked on a 64 bit machine. This was single of maybe 100 tries! Nothing has changed, the only changed variable was that I did the successful build immediately after computer restart.
I did clean/rebuild/restart VS/restart windows MANY times. I have reinstalled VS 2008 and now also the whole OS, it did not help.
EDIT: I have just managed to get one good build (out of next 100 :)) and did comparison between the deployed directories.
The source of the problem is that ClickOnce generates the wrong target platform in the manifest of the main .exe:
<asmv1:assemblyIdentity name="app.exe" version="1.0.4.18" publicKeyToken=".token here." language="neutral" processorArchitecture="<b>msil</b>" type="win32" />
processorArchitecture should be x86.
So the question is how to consistently force VS to generate the correct processorArchitecture in the manifest when deploying.
Can anyone help please?

This was resolved by installing VS 2008 SP1 on 64 bit Windows 7. VS2008 SP1 on XP had the problem on two machines I have tried with.

I had this problem as well, using VS2008 SP1.
In my case I had a 32 bit DLL which had to be compiled as 32 bit and an application that was using it in the same solution.
Even though I specified X86 as the build target for the release build, when I published a 64bit application was compiled and included in the installer.
I found a slightly brutal solution to the problem:
Go into the configuration manager and remove all possible configurations except the one that you want it to build (Debug and release versions).
After doing this I found that the clickonce installer was generated with the correct application.
I hope this helps someone else, I have been battling this problem on and off for months.

I'd suggest to use Reflector to open the main exe deployed by ClickOnce and see the dependencies to make sure you are not deploying the 64 bit version of the dll by mistake.

You must resolve to run 32-Bit Applications in IIS 7. See http://www.fishofprey.com/2009/04/badimageformatexception-in-iis-70-on-64.html

Sometimes the ClickOnce publishing process seems to cache old files from previous Any CPU or x64 builds. Doing a Clean and Rebuild All didn't fix this problem for me. I needed to delete all of the bin and obj folders from my projects and reopen Visual Studio.

We ran into this problem and determined that the subdirectory of the user profile to which ClickOnce deployed our application must have become corrupted, because we were able to deploy the application successfully with ClickOnce when logged in as a different user on the same machine.
We were able to solve the problem simply by deleting the subdirectory of C:\Users\<user>\AppData\Local\Apps under which ClickOnce was deploying our application. In our case, this was C:\Users\<user>\AppData\Local\Apps\2.0.