A true fix for this is now ready, but due to the nature of the changes involved, it will go to the upcoming version (5.33) - preliminary release date is April.

I can confirm the problem. It appears with other Web projects, too. It has to do with the new method of loading the internal assemblies. What happens there is that we (intentionally) reference both the so-called mixed-mode assemblies (assemblies created in C++ that contain native and managed code), one for 32-bit and other for 64-bit windows. During runtime, we reference and load the appropriate one. This works well in normal applications, but you have discovered a problem that affects all Web applications.

It appears that with Web applications, the host loads *all* assemblies right at the beginning, without waiting until they are actually needed. Therefore, when you run your Web app in a 32-bit environment, the 32-bit assembly will load fine but the 64-bit assembly has a "wrong format" and will not load. Conversely, when you run your Web app in a 64-bit environment, the 64-bit assembly will load fine but the 32-bit assembly (which we do not need) has a "wrong format", will not load, and will prevent the whole app from working.

Finding a solution for this won't be easy. But there already is a workaround: Whate happens is that the loader tries to load all assemblies it finds (in App_Code folder), but does not complain when an unneeded assembly is missing. If you manually remove the unwanted assembly (the one listed in the exception message) from the 'bin' subfolder of your project before running the app, it will work. There are, however, issues with this approach, such as:

1) You need to know upfront whether you are going to run the app in a 32-bit or 64-bit process.
2) Every project rebuild will place the assembly back to 'bin'. I think that this might be overcome by a custom build step.

I will need to have a deeper look at how to handle this issue, and more time.

Best regards

Note: 'amd64' is a correct designation under Intel processors as well. This is due to historical reasons of the processor development: The Intel's own 64-bit architecture (Itanium, IA64) has not been truly successful, besides a narrow market. AMD has come with much more successful 64-bit architecture, which Intel later copied is now using it basically everywhere. Hence the name 'amd64' in the assemblies. en.wikipedia.org/wiki/X86-64 , and more through Google...

Have you followed the installation instructions in What's New, and uninstalled QuickOPC 5.31 first, in order to remove the assemblies from the GAC?

If not and if this is the cause, the remedy would be either to manually remove the 5.31 assemblies from the GAC, or to (and that's kind of cumbersome): 1) install 5.31, 2) uninstall 5.31, 3) install 5.32 again.