Hello Everyone - I have a large project which is built using the "Any CPU' option in VB.Net 2010. On my test/development system, I am running 64 bit Windows 7, but on my production floor we have a mix of stations running 32 or 64 bit Windows 7 or Vista.
How can I deploy both version of the Chilkat DLLs so that my users are able to access the functionality no matter which platform they are on? I can not see a way to set my references up so that it chooses the correct library, and right now when a 32 bit user attempts to utilize the Chilkat functionality, the system throws an error and bombs.
Any assistance would be greatly appreciated!
Keith, thanks for posting.
First some background for other readers: The Chilkat .NET assembly is a mixed-mode assembly, which means the outer layer is a .NET managed API, but the inner core compiles to native code. (There is no COM involved.)
One possible solution is to explicitly target your app for 32-bit (instead of Any CPU) so that it runs as a 32-bit process regardless of platform, and it always needs the 32-bit Chilkat assembly. It's likely your app would run with very little performance difference. Here are a few snippets from some sources on the web discussing the issue:
In general, there is not a large performance increase by switching to 64 bit. This is because most programs are still written with 32 bit architecture in mind, and do not need more than 2Gb of RAM. The difference starts to shine when running things like 64 bit Photoshop or CAD programs where LOTS of RAM is used.
From a research paper entitled: "Performance Comparison of 32-bit and 64-bit Programs on the
AMD64 Architecture" at http://www.cs.ucf.edu/~wspires/32bit_versus_64bit_amd64.pdf
Having completed our experiments, several conclusions may be drawn. The main finding is that 64-bit computing does not automatically translate to a marked improvement in performance. If a program does not make use of 64-bit data types, then we will probably see little benefit in execution time. In fact, the execution speed may be worse, most likely due to issues with cache utilization. However, some programs that primarily operate on 32-bit data may still see a moderate speedup under the AMD64 architecture, most likely due to the additional GPRs added to the x86 instruction set. For programs utilizing 64-bit data types, such as many floating point heavy scientific applications, then an approximate 40% boost in performance can be expected, which provides a strong incentive to invest in a 64-bit system.
If your app does not use huge amounts of memory, and does not do significant floating point computations, you're probably best off with this simplest solution (target for 32-bit).
Assuming you still want to run as a 64-bit process when on a 64-bit system, then the solution really depends on your installer program -- i.e. however it is you deploy your application. You would want to look for a feature where you could conditionally deploy based on the architecture of the system. This was possible with the MS Setup and Deployment projects in Visual Studio 2005. See this Chilkat blog post: http://www.chilkatsoft.com/p/p_541.asp
Thank you for the response!
My application is pretty big, however, I don't see too much of a problem on individual workstations no matter which platform I compile to. However, several of my users run in the MS Terminal Server environment on Server 2008 R2 in 64 bit mode, and I notice a performance hit when the app is running 32 bit under several users on the same machine. If I had my choice, I would target 64 bit and leave it at that, but I have to support the legacy systems (sigh).
I guess the question for me is whether or not there is a way in the VS environment to specify which DLL I want to reference based on the platform you are building for. I have been using ClickOnce, which does not support conditional deployment. I may have to look for a different deployment method or compile the system individually to the different platforms and change the references manually each time I compile.
Not a Chilkat problem, it's strictly a deployment issue - there should be a more flexible way to do this...