We Keep Coding

"Unable to find an entry point named 'sqlite3_open_interop' in DLL 'SQLite.Interop.dll'."

I am using a C# application to try to connect to a SQLite database. The application uses the library System.Data.Sqlite, version 108. In Visual Studio 2017, my Solution Configuration is Debug, and my Solution Platform is Any CPU. Whenever I build and run the application, I get the following runtime exception:
The exception is unhandled, and the application terminates.
There is, of course, a SQLite.Interop.dll file in my bin\Debug directory. (If there wasn't, the exception would be different.) Specifically, there are two, each in their own subdirectories named x64 and x86. My assumption is that the file in the x86 directory is being used, since the Solution Platform is set to Any CPU. The version of the SQLite.Interop.dll assembly matches that of System.Data.SQLite.dll, being 1.0.108.0.
When I use the following command to interrogate the assemblies:
dumpbin /exports SQLite.Interop.dll
I do find the following line in the output for the x64 version of the assembly:
175 AE 00040750 sqlite3_open_interop
but in the output for the x86 version I do not. Instead, I find this line:
175 26 00037F10 _sqlite3_open_interop#20
which is close, but not a match. So there is indeed no such method as sqlite3_open_interop exposed by the assembly.
I have tried the obvious solution of changing the Solution Platform to x64, but that change leads to another exception (BadImageFormatException) which I don't much want to contend with.
I have tried dropping the reference to System.Data.SQLite and using Nuget to add the most recent version, 1.0.111.0, then cleaning and rebuilding the solution, but all to no effect. The same issue recurs.
Could anyone suggest a solution to this issue? SQLite is widely used, I believe, so I have to think there's a way to work through it.
*Edit1: I tried this project on my home computer, and observed the same difference between the two SQLite.Interop.dll files. The x64 version had a sqlite3_open_interop, while the x86 version had a _sqlite3_open_interop#20. However, the problem did not occur there. So apparently this mangled name "issue" is a red herring. I am still very interested in solving this problem, and would appreciate the assistance of someone who works on System.Data.Sqlite!

Delete your x64 and x86 directory then do a build. It will put the correct version in the folder when the installer does the NuGet check. For some reason, when you upgrade to a newer version, the x64 and x86 folders do not update the interop file in those folders if one already exists.

It turned out the issue was that the assembly was being blocked or disrupted somehow by McAfee Host Intrusion Prevention. The Activity log had the following message:
Attack type: DISA McAfee - Prevent unexpected DLL files from Running
in User AppData and ProgramData folders (Sig Id = 7020)
Which is odd because I don't think my program was executing in either such folder; in fact, there are no such folders, as I am looking at the matter. I was able to fix the issue by moving the program to My Documents.
It's also notable that the exception made no hint of interference by a security scanner.
Sigh. I don't know how generally useful this answer is, but I will leave it here. It might help someone. The admins can remove it if they deem appropriate.

Though its an old thread but nevertheless someone else may face similar issue again. In my case, this error occurs when I try to make connection string with password, since in the latest version of sqlite, ecnryption has been a paid feature that's why it doesn't work in free version. So, to circumvant this issue I restored old version of sqlite (picked from my old project) and it worked ok.
Add following reference in your project:
System.Data.SQLite.dll
Copy following files in binary folder:
System.Data.SQLite.dll.config (Optional)
System.Data.SQLite.xml (Optional)
x64\SQLite.Interop.dll
x86\SQLite.Interop.dll
Where 'x64' and 'x86' are folders
Packages available on nuget have same issue so you need old dll

Update-database failing - BadImageFormatException

We have a team of developers working on an Asp.Net MVC5 solution, and often after doing a git pull to get the other developers changes we need to update our local databases with any new Database Migrations (entity framework 6.1.3) which have been added.
We run update-database in the Package Manager Console to update the database. This worked until we changed all the projects to compile x64 output. Which was needed to resolve memory requirements.
However now I am getting :
System.BadImageFormatException: Could not load file or assembly 'My.Data' or one of its dependencies.
An attempt was made to load a program with an incorrect format.
When I run Update-database. I've cleaned down all bin and obj folders before recompiling (to ensure all output would be the same format x64).
It looks like the problem may be that the migrate.exe is not compatible with x64. SO,Original MSDN article.
However this post is for EF5. Is this still the case? And is there a workaround? if not it seems bizarre, its not as if x64 or EF are new additions to Visual studio.

Managed to find the answer.
The problem is that the enable-migrations command appears to have a
hard-coded path where EF looks for built DLLs of your project at
/bin/Debug, no matter what the actual build path is. When you change a
Project to x64, Visual Studio quietly changes your project's build
path to /bin/x64/Debug - while EF keeps looking in /bin/Debug. That
causes this vague System.BadImageFormatException
It's harmless to just change your Project build path to /bin/Debug and
magically, everything begins working like it's supposed to.
https://stackoverflow.com/a/23666717

XNA reference error, changed workspace and can't run

Me and a couple of my friends were on an army network when we wrote the game (XNA 4.0 for VS10 32bit PCs),
and now we got it and it gives some error when we try to run the XNA part.
I try to run the server, whose main consists of Initialization of the server class and the start method.
The program throws a BadImageTypeException on the ctor of the server class instance initialization.
Since my windows is not in english I can't really give you the exception in gives but I do have a warning that says:
"Warning 1 There was a mismatch between the processor architecture of the project being built "MSIL" and the processor architecture of the reference "Microsoft.Xna.Framework, Version=4.0.0.0, Culture=neutral, PublicKeyToken=842cf8be1de50553, processorArchitecture=x86", "x86". This mismatch may cause runtime failures. Please consider changing the targeted processor architecture of your project through the Configuration Manager so as to align the processor architectures between your project and references, or take a dependency on references with a processor architecture that matches the targeted processor architecture of your project. Game_Of_Throws_Server"
Kinda been waiting for a long time for the game to go WWW and we wanna keep working on it,
but this is a small but annoying problem that keeps us from continuing the development of the game.
Tried removing the assembly reference from the assemblies list and adding it again (The Microsot.XNA.Framework reference) but it didn't change a thing. Windows is Win7 64bit, VS is VS13Community version.
If anyone would like to skype or something of that sort to see the problem more clearely, send me a pm.

You'll get errors like that if the assembly you reference has a different target platform to the assembly referencing it e.g. You have an 'Any CPU' project referencing an 'x86' assembly. Are you certain that the 'Platform target' setting of the project producing this error really is set to x86?
If you're referencing the x86 version of Microsoft.Xna.Framework, you should change the project referencing it to also be x86. If an x64 version of Microsoft.Xna.Framework is also available, you can get creative with your csproj file to ensure the right one is pulled in based on the build you're doing (native Visual Studio support for switching references based on the target platform of the build is not good).

Visual Studio 2012 adds reference to wrong DLL

I was having trouble getting Visual Studio to build my project in release mode... it gives me errors about assemblies being the wrong format. Turns out some x86 assemblies were being referenced instead of x64 assemblies. Assemblies like PresentationCore, System.Data and so on.
Things I've tried:
Debug mode, any CPU builds fine.
Debug mode, x64 builds fine.
Release mode, any CPU fails
Release mode, x64 fails (this is the combination I'd LIKE to build my project in)
The issue comes when I try to remove the x86 reference and switch it to a x64 reference. Visual studio just adds the old x86 reference instead of the x64 reference. For example:
I remove the System.Data reference which is in C:\Windows\Microsoft.NET\Framework\v2.0.50727\System.Data.dll
I browse to and add C:\Windows\Microsoft.NET\Framework64\v2.0.50727\System.Data.dll, but when I click on that System.Data reference, the path is CLEARLY still to the old dll and causes the same error to occur. This is happening with several other DLLs as well.
Does anyone know of a solution to this issue?

Assemblies like PresentationCore, System.Data and so on.
I hate to answer a question without seeing the error message. But this secondary evidence is enough to answer the question. First off, this is not an error, it is a warning. It looks like this:
warning CS1607: Assembly generation -- Referenced assembly 'System.Data.dll' targets a different processor
You'll also see one for mscorlib.dll. And PresentationCore.dll in a WPF project. What goes on here is that these assemblies are special, they are mixed-mode assemblies. In other words, they contain both native code and managed code. The native code is the trouble-maker, such an assembly can only be used in a project that targets the right processor flavor. If you mix it up then you get a BadImageFormatException at runtime.
This is not a real problem with .NET assemblies, your machine actually has two versions of these DLLs stored in the GAC. One that will be used if your program runs in 32-bit mode and another that is used in 64-bit mode. The CLR automatically picks the right one.
However, there is only one version of the reference assembly, the one that's stored in c:\windows\microsoft.net and that you pass to the compiler to read the metadata from. It is always the x86 version, there's no other one so don't bother looking for it. Again, this is not a problem, only the metadata of a reference assembly is used by the compiler, it doesn't execute any of its code. And the metadata does not depend on the bit-ness of the assembly.
Nevertheless, this all might be a problem if you create your own mixed-mode assembly. You can easily overlook the need to provide two versions. So what the compiler is fretting about is that it sees that you asked for an AnyCPU or x64 build of your project. But detects that the reference assembly can only work when you target x86. So it squeaks at you a bit, just a gentle reminder that there's some evidence that you're getting it wrong and that your program might fall over on a BadImageFormatException when you run it. It doesn't otherwise treat a framework reference assembly any different from your own reference assembly.
So, feature, not a bug. Just a warning that doesn't otherwise prevents your program from building. You can safely ignore the warning since you know that .NET has the right assembly available in the GAC at runtime. Notable is that .NET 4.0 doesn't have this problem, it uses very different reference assemblies that don't have the ILONLY metadata flag turned off.

Odd behavior. Turning "Generate serialization assembly" off under Build in project properties makes the project build just fine in release mode. Looking at this link reveals that this setting has to do with XML Serialization, which we don't even use in our entire solution.
Very weird. Still looking for an explanation for this question and behavior here.

Check out what your build configuration looks like. Sometimes this error happens because certain project on a solution is configured to be built in one build configuration, and not in another.
To do this:
Go to "Compile > Configuration administration..."
On "Active solutions configuration" select "Release" which is the configuration that is giving you problems.
On "Platform of active solutions" check "Any CPU". If "x64" is defined, you might be able to choose it too.
Look at the list of build projects. All projects needed for the solution must be marked with the correct values in "Configuration", "Platform" and have a "Compile" check.
In my case I have a sandcastle project that I uncheck most of the times, at least in debug mode, because it takes ages to compile. Sometimes it happens that one project does not have a configuration for the "Release" configuration and thus, when the build process tries to get its results, these don't exists (there is no DLL) and it throws an exception. In other situations, it might be that a project is forced to compile for x86 (or x64) and the rest is not, and so an error is thrown when trying to link other referencing projects to the proper version of the referenced DLLs.

Which version of .NET are you compiling for? If you can change the project to a later version of the .NET framework, that might help.

My VS2010 web project was generating these warnings too, and IIS was throwing a BadImageException. The Build/Configuration/Platform settings looked ok, but the Output window was showing that the dll was built in x64 folder for Any CPU configuration. Deleted all folders under bin and rebuilt. The warnings were gone and the BadImageException was gone.

Error while trying to run project:The module was expected to contain an assembly manifest

When I try to run the project it says:
Error while trying to run project:could not load file or assembly 'Project.exe' or one of its dependencies.
The module was expected to contain an assembly manifest.
When I ran the exe from the debug folder I got this error:
application unable to start correctly (0xc000007b)
I also reinstalled Visual Studio but it doesn't seem to work!

The module was expected to contain an assembly manifest
It is a low-level assembly loading problem. The CLR has located a file with the right name but when it tries to load the assembly, it finds out that the file doesn't contain a proper manifest. A .NET assembly must contain a manifest, it contains metadata that describes the assembly, listing the types in the assembly, etc.
If you have no clue what EXE or DLL might be the troublemaker then you can use the Fuslogvw.exe utility:
Start it from the "Visual Studio Command Prompt".
Click the "Settings" button and click the "Log binding failures to disk" radio button.
Switch back to VS and start the program and wait for the exception to occur.
Back to Fuslogvw, click the "Refresh" button and double-click the added entry.
It shows you the file it found.
Several possibilities, a common one these days is to trying to load a .NET 4 assembly with an EXE that asked for CLR version 2. That requires an app.exe.config file that forces CLR 4 to be used.

In my case I just change Target Framework(.Net Framework 4) in Project Properties. It solves the problem.

I have the same problem when I use Vs2012 utimate to publish Asp.net Mvc4, then upload dll to server.
I fixed it by build code as Release mode then upload all dll in bin folder to server.

IN my case it get fixed by just going to project properties and set-->startup object projectname.program and build->platform target--> x86.

i just resolve this by problem by restarting System as well in project properties i set to multi users as well in combo box start option.hope this will help u.

0xc000007b is "STATUS_INVALID_IMAGE_FORMAT". From experience, this points me to the project properties.
A few things worth checking out:
Check to see if all the build options are set to either x86 or x64, depending on your system architecture, or AnyCPU.
If you're using dlls, consider whether they were compiled for your target architecture or not. If not, then recompile them accordingly or get them in the right version from wherever you got them.
Finally, check if your project assembly and loaded assemblies have different names. That seems to make things go boom as well.