32-bit vs 64-bit dll's - "An attempt was made to load a program with an incorrect format"

We've run into an issue deploying our ASP.NET website on our production server. On our local development machines (64-bit) we are using the 32-bit dll's and everything works fine, but when we load the same ones on the production server we get the following error:

Could not load file or assembly 'Leadtools.Codecs' or one of it's dependencies. An attempt was made to load a program with an incorrect format

I've setup the application pool in IIS to "Enable 32-bit Applications" so it should load the 32-bit dll's. We've also tried using the 64-bit dll's but those do not work either. I currently don't have access to the production server for testing purposes, but I setup a copy of the website on another server on the same network and it works with the 32-bit dll's. The Windows versions are different on each server, but they are both 64-bit operating systems. The production server is using Windows Server Standard without Hyper-V Service Pack 2 and the other server on the network (the one that works) is using Windows Server 2008 R2 Standard Service Pack 1. Would the different Windows versions be causing some conflict with dll's or is something else causing this issue?

Hello,

This is very similar to the issue in this forum post:

https://www.leadtools.co...-its-dependencies--Excep

It sounds like you are trying out the same approach to solve it as I suggested, but when you change the Application pool in IIS for 'Enable 32-bit applications' to true, please make sure you perform an IIS Reset and clear the cache before testing it again to see if it worked.

One other thing to check is to see what windows features are turned on by default on the server to make sure that IIS is enabled correctly. Here are 2 images showing the minimum that needs to be enabled:

Hi Hadi, thanks for the reply. So I was given production server access again to test this, and the error is actually different than the one I initially posted. Using the 64-bit dll's gives that error, but when using the 32-bit dll's it gives this error:

Could not load file or assembly 'Leadtools.Codecs.DLL' or one of its dependencies. The specified module could not be found.
Exception Details: System.IO.FileNotFoundException: Could not load file or assembly 'Leadtools.Codecs.DLL' or one of its dependencies. The specified module could not be found.

Again, I have this exact same website set up on another server and it works fine when using the 32-bit dll's. I checked all of the app pool and website settings in IIS on each server and they are the same. All of the LeadTools dll's are in the bin folder of the website, so it should be pulling them correctly. I'm not sure why it says it can't find it.

Also, to your other point about the Windows Features, we are using Windows Server 2008 and it does not show the IIS features you're showing. We do see the HTTP / Non-HTTP activation, but those are off on the server that works, so those don't seem to be the issue. I think this comes down to how IIS is trying to load the dll's, but I can't seem to figure out why it won't load them directly from the bin directory, because that's where they are.

Do you have the Microsoft Visual C++ 2010 Redistributable Package for both x86 and x64 installed on the machine?

The LEADTOOLS libraries have dependencies on these packages depending on which .NET framework you are targetting.

You can read more about them here:

https://www.leadtools.co...th-your-application.html

Runtime Files Requirements in .NET 2.0 or later
LEADTOOLS binaries for .NET 2.0-3.5 require redistributing Microsoft Visual C++ 2008 runtime files.
LEADTOOLS binaries for .NET 4.0 require redistributing Microsoft Visual C++ 2010 runtime files.

If the above already exist on the machine, then you need to double check that your project CPU and .NET framework match the referenced Leadtools dlls CPU and framework.

Here is how you can check the Details of the Leadtools dlls to ensure that your using the correct ones:

Edited by user Wednesday, February 10, 2021 11:15:04 AM(UTC)  | Reason: Not specified