System.BadImageFormatException: Could not load file or assembly 'Leadtools,

I'm having trouble running a .NET application which uses LeadTools v16 (Document Imaging) on Windows Server 2008 R2 Enterprise, 64 bit.

To deploy the application:

- I have copied the .NET application with the LeadTools libraries it uses in its bin folder
(Leadtools.dll, Leadtools.Barcode.dll, Leadtools.Codecs.dll, Leadtools.ImageProcessing.Core, Leadtools.ImageProcessing.Utilities)

- ensured the library Ltbar4u.dll is in the %windir%\system32 folder

This is sufficient to run the application on a Windows 2000 machine (using it in a production environment right now).
However on the Windows 2008 64 bit machine, I get this exception:

Service cannot be started. System.BadImageFormatException: Could not load file or assembly 'Leadtools, Version=16.0.0.0, Culture=neutral, PublicKeyToken=9cf889f53ea9b907' or one of its dependencies. An attempt was made to load a program with an incorrect format.

File name: 'Leadtools, Version=16.0.0.0, Culture=neutral, PublicKeyToken=9cf889f53ea9b907'
at ***.Startup()
at ***.Service.OnStart(String[] args)
at System.ServiceProcess.ServiceBase.ServiceQueuedMainCallback(Object state)

=== Pre-bind state information ===
LOG: User = ***
LOG: DisplayName = Leadtools, Version=16.0.0.0, Culture=neutral, PublicKeyToken=9cf889f53ea9b907
(Fully-specified)
LOG: Appbase = file:///C:/Program Files (x86)/***/
LOG: Initial PrivatePath = NULL
Calling assembly : ***, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null.
===

LOG: This bind start...

***: application and username removed

Any idea what could cause this problem, am I missing something or not deploying it correct on the machine?

Edited by moderator Tuesday, November 22, 2016 10:19:01 AM(UTC)  | Reason: Updated topic title

Are you building your program as a 32-bit or 64-bit process? If you're using the 'Any CPU', you could get similar problems on 64-bit machines because the process could try to load mixed 32-bit and 64-bit DLLs.

If you want your process to be 32-bit, you should specify the x86 CPU option in the configuration manger, and only use the 32-bit editions of our DLLs. You should normally deploy these DLLs in the same folder that has your program's EXE, but if you want to put them in the system folders, do NOT put any of them in the SYSTEM32 folder on a 64-bit machine. Instead, put the 32-bit DLLs in the Windows\SysWow64 folder.

If you want to build the program as 64, also specify the platform and make sure to deploy our 64-bit DLLs with the EXE.

Thanks,
Maen Badwan
LEADTOOLS Technical Support

Reply to your questions:
- I was building the application as a 32-bit process, with solution platform 'Any CPU'.
- I want the process to be 32-bit.

I followed your advice and it solved my problem for my windows service which uses LeadTools:
1. build with x86 option
2. install and manually copy Ltbar4u.dll to bin folder
=> problem solved

I also have an HttpHandler which uses LeadTools, but the steps above didn't solve it for this application.

I get an error while registering the HttpHandler in IIS via "Add Managed Handler"
=> "Could not load file or assembly 'LeadTools.Barcode' or one its dependencies. An attempt was made to load program with an incorrect format."

The error stays when i move the Ltbar4u.dll file to %windir%\SysWow64 instead of the application's bin folder.

As a test i added a WebForm (.aspx) to the website with the same functionality as the Handler (.ashx).
I still can't register the HttpHandler, but the webpage works perfectly.

So I do have a workaround, but it would still be nice if I could get the handler working.

Thanks for looking into my problem.

I haven't tried to use our DLLs with a web handler before, but I don't think there should be a problem doing that.
The general rule is that the correct edition of our DLLs needs to be loaded by the process. Since it appears you're using 32-bit IIS and it works with a web server application, can check to see if our barcode and other DLLs are being loaded by the application when you get the error?
As a test, try to add our .NET DLLs, including barcode files, to the Global Assembly Cache (GAC) and see if the application works with them.

Thanks,
Maen Badwan
LEADTOOLS Technical Support

In case someone is searching for BadImageFormatException and comes across this post, I recently posted an article on our blog about the BadImageFormatException that explains what to look for when trying to solve this problem.

https://www.leadtools.com/blog/general/badimageformatexception-and-leadtools/

The exception that is thrown when the file image of a dynamic link library (DLL) or an executable program is invalid. If you get a BadImageFormatException when interfacing with a native DLL, it almost always means that you are trying to interface with a 32-bit DLL while running in the 64-bit CLR, or vice versa. In most cases you might be facing the problem with your website after deploying on server.

Make sure that you are not having 32-bit / 64-bit conflict. So, you need to adjust your application pool to Enable 32-Bit or 64-Bit accordingly. Set the Target platform setting on your c# EXE project, not your class library project. Alternatively, you can ship both 32-bit and 64-bit DLLs with different file names, define separate P/Invoke stubs for each version, and decide which one to call at runtime. The easiest way to do this would probably be to wrap your native calls in an interface (e.g., INativeMethods) and choose which implementation to instantiate at runtime based on IntPtr.Size. With this method, you could still target AnyCPU.