The problem
When writing .NET applications that need to interoperate with (legacy) 32-bit ODBC drivers, COM libraries and such. You might run into problems on 64-bit OS installations. By default applications written using the .NET Framework 4 or earlier will be compiled with the “Platform Target” option as “Any CPU”. When such an application accesses a 32-bit COM component on a 64-bit machine you might see the following kind of exception:
This operation failed because the QueryInterface call on the COM component for the interface with IID ‘{YOUR-GUID-HERE}’ failed due to the following error: Old format or invalid type library. (Exception from HRESULT: 0x80028019 (TYPE_E_UNSUPFORMAT)).
When trying to access and ODBC connection you might find that there are 64-bits and 32-bits ODBC connections. And that older drivers can only be used for 32-bits ODBC connections.
Solution 1
If you catch this during in-house testing you will be able to fix the problems by forcing the compiler to use the x86 platform. By going to the project properties, than go to the “Build” tab and setting the “Platform Target” to “x86” like so:
However, be aware that this is a configuration specific setting, so if you are wondering why your release builds are still giving you these problems you should also apply this setting for the Release configuration.
If all of the components in your solution should be built using the x86 platform target or if you want to be able to create separate x64 and x86 builds it is probably better to create solution platforms for both. You can do this by right clicking on the solution and choosing “Configuration Manager”:
Here you can create custom solution platforms and allow you to select the project’s platform for each of your projects.
Solution 2
If you are using the .NET Framework 4.5 from the start of your project you might have noticed you do not run into the above problems. This is because of a new setting that is on by default called “Prefer 32-bit” (this settings was conveniently greyed out for met .NET Framework 4 project screenshot above).
If it is possible to upgrade to the .NET Framework 4.5 then this is a much cleaner way of dealing with things. Though just upgrading is not enough, after the upgrade you DO need to actually check the box to enable it.
More info on this option can be found here: http://blogs.microsoft.co.il/sasha/2012/04/04/what-anycpu-really-means-as-of-net-45-and-visual-studio-11/
Solution 3
So what if you shipped your product built in .NET 4.0 and the Platform set to “Any CPU”. The customer might not want to upgrade to your new and improved version, and you don’t want to rebuild the version he is using. Or you just found out and a release with the fix might be months away (and of course the customer can’t wait that long).
When that happens it is time to fall back to solution number 3: CorFlags.exe which is a tool installed with Visual Studio and is available from the “Developer Command Prompt”.
This tool allows you to edit the header section of your .NET executable. And can be used in the following way:
CorFlags.exe MyApp.exe /32BIT+
or
CorFlags.exe MyApp.exe /32BIT+ /Force
The latter is used if you have a strong signed assembly. This will break the signing so be careful with that. More info on the tool can be found here: http://msdn.microsoft.com/en-us/library/ms164699(v=vs.110).aspx