|
<< Click to Display Table of Contents >> Navigation: Programming with Common Vision Blox > Multi-Platform > Portable Code > Migration of Existing Applications |
The types used in the DLL interface are practically identical between Win32 and Win64 (of course with the pointer types being 64 bits wide, but that is handled implicitly as long as no conversion between pointer types and integer types happens in your code).
So for the DLL interface all that needs to be done is to adapt your code to the breaking changes that have been made to the DLL interface.
With the ActiveX controls, there is the added complication of the differing type library (and therefore the need for different wrapper classes on the different architectures).
You should, at any rate, replace the C++ wrappers for ActiveX controls that have been generated for Win32 with the ones found in the %CVB%\Wow6432\Visual C++ OCX Wrappers folder:
If you don’t, the old Win32 wrappers will only marshal 4 bytes for each Image pointer through the OCX’s IDispatch interface even if compiled for x64 without even raising an error.
This will work for quite a while (while memory consumption in a process is still low, the upper 32 bits of pointers on Win64 tend to be zero…), but sooner or later this will lead to intermittent problems that will be very challenging to debug.
If your application uses the Display’s UserPaint event or the DigIO Control's Listener or Toggler event then make sure to adapt the event signature and the MFC macros for event marshalling according the description in the section about ActiveX controls.
Once these changes have been made to a project, it is ready for x64 compilation.
Transfer it to your x64 development machine if you have not already done so and add "x64" debug and release configurations to the Visual Studio project (you can simply base all the settings on the corresponding “Win32” platform configurations).
Note that even though you can run the Win32 build result of some applications on the x64 platform this is not a supported configuration and unlikely to work properly for more than a few minutes!
It is not strictly necessary to adapt your project to the new type system outlined earlier for it to compile and run on x64. If, however, you want to target Linux at some point, a switch to the new type system will be inevitable.
With the .Net languages, migrating a project is no more difficult than with C++.
The first step will be to add the newly built DllImport wrappers to your project references.
Doing so will make the compiler point out the locations of breaking changes to you, so fixing those will be fairly straightforward.
What requires more attention is the handling of the ActiveX controls.
Make sure you do the port on a Win64 development system – otherwise the ActiveX wrappers will be built versus the wrong (Win32) type library.
Remove your projects’ obj and bin folders – this will force Visual Studio to rebuild the ActiveX wrapper DLLs.
Note that ActiveX Control usage will not work when using .Net 4.0 as the targeted framework version (for details see the next paragraph)! When using C#, once the ActiveX wrappers have been recreated all problematic property assignments from 64 bit integer values to 32 bit integer values will be pointed out by the compiler (C# does not support automatic conversion from System.Int64 to System.Int32). VB.Net unfortunately is less strict here, and it is highly recommended to search your code for such assignments and correct them.
Consider upgrading your code to use the new shared object types introduced in CVB 2011.
For portability this is not a requirement, but these types go a long way to helping you make sure the CVB reference count is being used properly.
If you migrated your application to Visual Studio 2010 and want to target the .Net Framework 4.0 there is yet another pitfall waiting for you: By default, the ActiveX wrappers generated by Visual Studio 2010 with the .Net Framework 4.0 toolset will be specific to the platform of the ActiveX control for which they have been generated (in our case, the “_wow” versions of the CVB ActiveX controls).
In other words: The thus generated wrappers will be targeting the Win32 platform and when trying to load them into a Win64 application, the .Net Runtime will throw a System.BadImageFormatException.
In order to coerce Visual Studio 2010 into generating “Any CPU” wrappers with the .Net Framework 4.0 toolset (namely aximp and tlbimp) it is necessary to manually modify the csproj or vbproj file:
•Locate all the PropertyGroup nodes containing a Condition entry of the form ‘$(Configuration)|$(Platform)’==’Release|AnyCPU’ (in a typical project there would be 2 of these nodes: One for Debug|AnyCPU and one for Release|AnyCPU).
•For all those nodes where the condition states AnyCPU add an entry <PlatformTarget>AnyCPU</PlatformTarget>
With these changes applied, the automatically generated ActiveX wrappers will be loadable into an AnyCPU application running on Win64.
The same change is also required for C++/CLI projects, which, by default, always target the .Net Framework 4.0.