There are several elements to consider when migrating to RAD Studio XE8 from an older version (see tomorrow’s skill sprint for a live demo). The first is the new Settings Migration Tool, which helps you reconfigure the IDE according to your preferences. The second is the migration of any component, and of your code. This blog post focuses on the Settings Migration Tool.
The Settings Migration Tool
The Setting Migration Tool is a new tool that ships for the first time with RAD Studio XE8 (and also Delphi and C++Builder). You can find this tool in the product installation bin folder (like
C:\Program Files (x86)\Embarcadero\Studio\16.0\bin
) under the name
. If you run it, it has a wizard UI guiding you through a few pages.
The concept behind this tool is quite simple: The IDE saves its configuration settings in the registry, and each version installed on a computer will have its specific settings. The Setting Migration Tool offers an easy way to copy some or all of the settings from the area of the registry for a version of the product to a different area storing the information for a different version.
The same tool can also be used to export the settings to an external XML file, move it to a different computer (provided the folders configuration is similar) or virtual machine, and re-apply the same settings on a different computer. This can be used when a developer moves his license to a different computer, if the developer has multiple computers with the product installed (a scenario the license allows), or just to copy the settings of a developer to the computer of another developer of the same team (or another developer in general).
Finally, you can use this tool to create a backup of your settings, or move settings between different configurations on the same machine.
Install and Migrate
The most common scenario for using the Settings Migration Tool is likely the first time you install XE8. Notice, thought, that installing the product doesn’t create the user registry settings (by default), but only the system ones. You’ll have to run the IDE a first time to create the default settings. At this point close the new IDE, use the Settings Migration Tool, migrate the configuration of an older version, and reopen the new IDE.
Settings to Migrate
When it comes to migrating settings from one version to another or from one machine to another, you seldom want to migrate everything (unless you are doing this for backup reasons).
The Settings Migration Tool lets you pick any area of the registry for the product (under
), but not all of them make sense. PlatformSDKs, for example, require a version specific installation. Design-time packages configurations generally refer to files on a specific computer, and of a specific version of the IDE.
You’d generally want to migrate editor settings, general IDE settings and default compiler/linker settings. The tree of options is quite large and deep, and here I’ve listed only the elements at the first level:
I really recommend you to spend a little time getting familiar with the settings when doing a migration. You’ll really never want to move everything and select all nodes.
Migrating Alternative Settings
As some of you might know, the Delphi, C++Builder, and RAD Studio IDE can be executed with an alternative configuration, that it automatically created from the defaults the first time it is used. This happens by running the IDE with the
command line parameter. The issue with this approach is that all of your IDE settings are not copied, and you get the default settings.
However, you can first save them to the XML configuration file, with the Settings Migration Tool and later re-execute the tool with the same
to make is work on the alternative registry configuration.
When Things Go Wrong: Restoring from a Backup
Finally, I want to mention that every time the Settings Migration Tool writes to the registry, it also creates a backup of the existing configuration. In case something goes wrong (the Ide might not even start, in the worse case scenarios) you can execute the tool again and restore the settings from the backup file.
Migrating the Actual Projects
Now what about migrating existing projects? Well, that worth a separate blog post, and an focused skill sprint. Suffice to say that migration of code from iOS 32-bit to iOS 64-bit is surprisingly simple… and much simpler that using any of the other native development tools currently available.
As for migration of other project types, the migration of VCL code is generally smooth, after you’ve converted your code to Unicode. Notice, though, that you need to have any third party component updated to the current versions (as component packages are version specific), or have their source code to recompile.
One specific addition to the “conversion” toolset is the availability of a specific set of components and some search and replace (reFind) scripts for migrating code that uses the dbExpress database access engine to the newer FireDAC database engine.
That’s All, Tune in the Skill Sprint Tomorrow
As the title says, see you at tomorrow for a 20 minute skill sprint focused on the same topics covered in this blog post. Details, time of the different sessions, and sign up at