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.

C++ CLI DLL not being loaded by IIS7 but only if built with anything newer than VS2008

For my development environment I'm using Windows 7 Ultimate x64, with VS2008, V2010 and VS2013, and my application is written in C#.
The remote test server has Windows Web Server 2008 R2 x64 and IIS 7.
Here is my specific issue:
I have a native C++ library that I want to use in my C# applications, so I wrote a C++ CLI/CLR wrapper around it, and compiled it all into the same DLL. I've tried both compiling the C++ source into the DLL, and also statically linking the native library into the DLL, and both give me the same result as described below.
If I build this DLL using x64 and .NET 4.5.1 with VS2013, then this DLL works fine with any C# Winforms application in and out of the development environment. It also works when referenced in an ASP.NET application within my development environment (using x64 IIS Express to test). It does NOT work when the web application is deployed (as an x64 build) to the Win2K8 IIS7 server, displaying an BadImageFormatException. I do not build for "AnyCPU" because of the CLI wrapper DLL, which needs to be built for a specific platform.
I have also tried the .NET4.5.1 x86 version of the CLI DLL (using VS2013), and it also works fine with all Winforms applications, and works with ASP.NET on my development machine (using x86 IIS Express), but it does not work on the Win2K8 IIS7 server (x86 build). Same BadImageFormatException error when trying to load this DLL.
On the server it uses an integrated application pool because of the ASP.NET Identity code (won't let me use Classic mode). Also, the "32-bit applications" setting has been toggled to both True/False, and neither has helped solve this issue.
If I build the C++ CLI DLL for .NET 2 or .NET 3.5 and the x86 platform with VS2008, or even VS2013, but selecting VS2008 (V90) as the platform toolset, then it works perfectly fine on the Win2K8 IIS7 server, with no BadImageFormatException error. The ASP.NET integrated app pool "32-bit applications" setting is "True" in order for this to work.
If I build the C++ CLI DLL as .NET 2 or 3.5, x86 platform, but with anything newer than the VS2008 toolset, it fails to load on the IIS server, with BadImageFormatException, even though it works fine on the development machine ASP.NET and in any Winforms application.
Using VS2008, .NET 2 or 3.5, and platform x64, the DLL works in any Winforms app, works with ASP.NET/IIS Express x64 on the development machine, but does NOT work on the Win2K8 IIS7 server, displaying BadImageFormatException. The application pool "32-bit applications" was set to both True and False for testing.
So, in summary, the only option that works on IIS7 is building with the x86 platform selected, using the VS2008 (V90) toolset.
Has anyone experienced anything like this or have an idea what may be causing this issue. I can't see anything drastically different between the working DLL and the others using JetBrains dotNetPeek 1.1, but that's only really a look at the surface... all the code exists in there. Could there be an option in the V100 or higher toolset that is embedding something in the DLL (or leaving something out of it) that is causing it to not be loaded on IIS7?
Any help or suggestions would be appreciated.

Ok, so after struggling with this issue for almost a month now, and resorting to asking on here last night, I came across these links:
Identifying problematic dependencies in C++/CLI project
and
http://www.codeproject.com/Articles/442784/Best-gotchas-of-Cplusplus-CLI
While they didn't actually specify the solution, there was something in there that I hadn't tried yet, which was to check if the Windows 2008 R2 server required the VS2013 C++ redistributable packages.
I installed both the x86 and the x64 redistributable packages, and suddenly my x64 ASP.NET app that uses the managed C++ wrapper for the native C++ library came to life. Everything is working as intended now. I can compile the wrapper DLL with the VS2013 toolset, x64 platform, using v4.5.1 of .NET, and it works perfectly fine. I no longer require the VS2008 toolset.
So much for BadImageFormatException throwing me off completely. I wish the error displayed on the Win 2K8 IIS7 server was actually more specific, but then again maybe that is just me asking for too much.
I hope this helps someone else.

Program works only on some pc, DLL missing?

I wrote with VS10 the following projects:
a C# (.net 4.0) program which calls
a C++ unmanaged dll, which make use of boost::thread
a setup project which includes the C# executable, the C++ dll, the boost::thread dll and some other files. Moreover during the installation there is a check if the framework .net 4.0 is installed, and if not it will be downloaded.
The compilation (x64 for each of the three projects) is ok, and the program works on my pc (Windows 7 64bit).
I tested the program on some other computers (all Windows 7 64bit) and I noted that:
in the ones with VS10 and Boost the program works
in the ones without VS10 and Boost the program gives an error in the C++ Dll
I think the problem is that some boost Dll is missing. Am I right?
Or the problem could be related to VS?
edit:
I have to mention that the structure of the program is the following:
main form (C#) in which some parameters are set, then a backgroudworker calls
the C++ DLL which do its stuff and uses boost::thread
it does some computations
when it get some results, writes them on file
continue with its computations and so on
the main form has a filesystemwatcher which looks for the results file and do some stuff with the results.
Also, when I get the error, the main form correctly loads and the parameters could be set. The error happens when the backgroundworker starts his work (calling the C++ DLL).
So I'm quite sure that there is no problem with the framework installation.
Update:
It turns out that I forgot to include some DLLs in the setup project. Now, including them the error changed.
Now, at the same point as before (and on the same computers) I get another error:
BadImageFormatException: An attempt was made to load a program with an
incorrect format
I read this article, but I have set x64 in both C# project and in C++ DLL and the setup project has as TargetPlatform x64. Any idea?

VCRedist package is missing on target machine. It should be available in VS SDK directory. Also you may need to install .Net Framework on target machine (.Net Framework contains VCRedist package). If you don't have instalation files for those, they are available on microsoft sites i.e. VC10Redist for x64 is here

In such cases I use the tool Dependency Walker
Launch it and select your executable to discover the missing libraries.
It gives clues indicating what is needed to install then.

If your C++ DLL is dynamically linked to the CRT, then you have to deploy also the VC++ CRT DLL's, i.e. MSVCR100.DLL and C++'s MSVCP100.DLL on the target machine (they are already available on your dev machine, where you have VS2010 installed, so on that machine your C++ DLL loads fine; but you can't assume that on your client's machine the CRT/C++ DLL's are available).
There are several deployment options: you may want to read this documentation on MSDN.

I finally found the solution!
The C++ DLL needs the mpfr library for multiple precision floating point computations with correct rounding.
I was including (shame on me!) the incorrect version of the library (x86) and this was the motivation for the error:
BadImageFormatException: An attempt was made to load a program with an incorrect format
Then in all the computers (three different computers!) in which the program was ok there were both (unlucky and misleading coincidence):
Boost and VS10 installed and
a x64 version of the library in a folder contained in the Path environment variable.
So, in some way the program found the right version of the DLL.
Including the right version of the library in the Setup Project fixed the problem.
Thanks to Kamil Klimek, Stephane Rolland and Mr.C64 for their precious suggestions.

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.