Question:

When building my C# solution I get the following warning on several of the projects:

 

Severity Code Description Project File Line Suppression State
Warning There was a mismatch between the processor architecture of the project being built “MSIL” and the processor architecture of the reference “ChilkatDotNet47, Version=9.5.0.75, Culture=neutral, PublicKeyToken=ab5fc1f999ef09bd, processorArchitecture=AMD64”, “AMD64”. 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. MyTestProject

 

Please could you advise if you  have a build that is MSIL compatible?

 

Answer:

The Chilkat .NET assembly is a mixed-mode assembly, meaning that it’s a managed layer on the outside, but with a native inner-core (C++ compiled to native code). Therefore, it cannot exist as an “Any CPU” assembly and must exist in 32-bit or 64-bit form. In your C# application’s project Properties, look at the options under the “Build” tab, as shown in the image below. When “Any CPU” is chosen, you will get the warning. The warning may be ignored if it’s the case that when the application actually runs it has the correct 32-bit or 64-bit assembly to load.

You’ll notice a “Prefer 32-bit” checkbox. This is checked by default. It means your application will always run as a 32-bit process, even on 64-bit machines. If this is the desired behavior, you may target the application for x86 (32-bit) because it will always be running as 32-bit anyway. You would reference the 32-bit Chilkat assembly, and there would be no warning.

Or you may uncheck “Prefer 32-bit”, target x64, and reference the 64-bit Chilkat assembly. This would also eliminate the warning. Finally, you may keep “Any CPU” and ignore the warning — just make sure that at runtime the correct matching DLL (32-bit or 64-bit) is present and loaded.

Also, see this for dynamically loading the correct .NET assembly at runtime: http://www.cknotes.com/dynamically-loading-net-assembly-32-bit-or-64-bit/