Having recently upgraded to a 64 bit system, I encountered a problem of which I was ignorant before. The default setting of a Visual Studio project is "Any CPU". On a 64 bit system this means the program will automatically run as a 64 bit application. On a 32 bit system it will automatically run as a 32 bit application. This sounds ideal.
Problem #1: Data residing in "legacy" data sources such as Excel documents, Access data, or third party databases must run as 32 bit clients. The "Any CPU" setting causes the previously working code to stop working. Changing your application to 32 bit enables this code to work again.
Problem #2: Third party DLL's, which are 32 bit in nature, cannot be accessed from 64 bit clients. I have yet to see any workarounds for this that actually work. Apparently .NET DLL's will auto-adjust if compiled with "Any CPU" and called from a 32 bit or 64 bit host client.
Problem #3: The Click Once deployment process seems to be broken. Applications deployed in the field, which used "Any CPU" cannot be updated. Changing your program to "32 bit" (or 64 bit) and pressing "publish" warns you that your version differs than your previous publish. If you actually tell it to go ahead your clients will lose all linkage to your project and require manual uninstall/re-installs.
As a temporary workaround I have started coding all my deployed code, which requires 32 bit data access, as a 32 bit application. I am no longer using the "Any CPU" setting on applications. Legacy programs deployed already, with the "Any CPU" option, are left in the "Any CPU" setting knowing that it will break on 64 bit systems.
I would prefer to put all my legacy 32 bit code into a DLL however that quickly renders it useless as 64 bit clients appear to have no means of communicating with 32 bit code.
I have yet to come up with any solution to my deployment problems.
Does anyone have some advice on these or similar problem?