.NET AnyCPU application running in 32 bit mode on 64 bit machine
At work we have a Continuous Integration system which builds every 15 minutes or so. While this helps us to quickly identify 'bad' code, at times it can lead to a false sense of security. I noticed this the other day when troubleshooting a bitness issue with one of my utilities.
On my Development machine I could build & test my exe in 64 bit mode. Once the code was built by the CI system it would only execute in 32 bit mode, which caused me problems when connecting to an Oracle server. I would get errors like this when trying to open a database connection:
Error: Could not load file or assembly 'Oracle.DataAccess, Version=2.111.6.20, Culture=neutral, PublicKeyToken=89b483f429c47342' or one of its dependencies. An attempt was made to load a program with an incorrect format.
at Vendor.DbCore.Oracle..ctor(String ConnectString)
at Vendor.DbConnectors.Oracle.Initialize(String RightsLocation)
References (In case my simple solution doesn't work):
- .NET 'Any CPU' targeted Winform EXE runs as 32-bit on *some* Vista x64 computers [social.msdn.microsoft.com]
- AnyCPU Exes are usually more trouble than they're worth [blogs.msdn.com]
- Visual Studio “Any CPU” target [stackoverfow.com]
- I've built a Windows service as “Any CPU”. Why does it run in 32-bit mode on my 64 bit machine? [stackoverflow.com]
Investigation
My application is a .NET 4.0 WinForms application. It is configured to target 'AnyCPU' (Debug) under Properties -> Build -> Platform Target. When built with the CI system it shows up in Windows Task Manager with the *32 tag at the end (shows that it executes in thirty two bit mode).
When I changed both Debug and Release to 64-bit only the CI system builds it in 64-bit mode (no *32 in task manager)
Solution
In my case the solution was simple: Change both Release and Debug to AnyCPU mode. Even though my application is a development tool / utility (and the project is attached to the special 'utilities/tools' project), it is still being built in Release mode. Case closed. :)
Final Notes
- If the simple solution listed here doesn't work, refer to the References section at the top. There are a few other things that can be causing the problem.
- If you have issues with the Oracle .NET connector, ensure that you have the correct 'bitness' installed. If you don't you'll see a message pretty much identical to the one I list above
- The Oracle .NET client has a few publisher policies that help you avoid re-compiling for every new version of the connector. I've noticed that on some systems these don't get installed. If that is the case you will see a similar message to what I list above. For Oracle clients that are installed to the Default location with Patch 9966926 installed you can find the publisher policies in this location: