Changing the target processor type of deployed ClickOnce applications
|
Last summer I set up a new development machine with a 64-bit O/S. Most of the struggles I had with were a few development tools that required special install packages for 64bit. One of those, which is ubiquitously in my "can't live with it, can't live without it" list is Crystal Reports. I spent so much time sorting out issues with Crystal on my X64 machine that I shared these experiences in this article for ASPAlliance. When compiling .NET apps in VS2008, by default they target "Any CPU". When the app is deployed on an x64 computer, it expects to find x64 compatible assemblies. In the case where you are using Crystal Reports 2008, the application gets confused because there is no 64-bit runtime for CR2008. However, the message tells you that you have the incorrect runtime installed. The message is misleading. In fact, the solution is to explicitly target x86 when you build your applications. (see the MSDN topic: How to: Optimize an Application for a Specific CPU Type for more info on this). When a client recently reported the error to me, I recognized it immediately. One of their remote employees had purchased a new computer with an x64 Operating System and he was having a problem with the reports (Crystal Reports) in a ClickOnce deployed application that the client has been using for about 4 years. Identifying the cause was only the beginning. I spent over a day re-targetting, rebuilding and redeploying the various assemblies for the app, but could still not get it working. The most telling problem was that when I had the main exe for the application targetted to x86, I received a lot of errors from the ClickOnce Mage UI tool when I attempted to save the manifest. The resulting manifest was invalid and broke the ClickOnce functionality on the client machines. Finally, I had had enough with rebuilding and futzing with the assemblies and started to focus on the ClickOnce manifest. I realized that although all of my assemblies were targetted to x86, the manifest itslef was targetting "msil" and also needed to target "x86". This was the cause of the problem related to the exe. So, I solved the problem with the manfiest and in the long-run solved the problem with the Crystal reports in my app. But the change broke my deployment. The new x86 manifest was now incompatible with the already deployed applications. Every user will get an error when they start their application and there is only one, quite unpleasant, solution. Each user must completely remove the current application and then reinstall it again. After I got to this point, I knew enough to do a web search on the proper key words and sadly confirmed my findings. For now, we've rolled back the deployment so that my client can prepare the end-users for this problem. We knew that sooner or later this would happen anyway, though it would have been a little less stressful if it had been planned for. But then, where would the fun be? |

