2. Upgrading RTI Connext
2.1. Upgrading to a Major Release
For instructions on upgrading from one major (three-digit) Connext release to another, see the Migration Guide on the RTI Community Portal (https://community.rti.com/documentation), particularly these sections:
The Migration Guide contains information about changes in your new release that may break previous functionality.
2.2. Upgrading to a Patch Release
Follow these instructions for upgrading to a four-digit Connext patch release. See also the release notes supplement that comes with the patch for any additional instructions.
2.2.1. General Patch Installation Steps
Generally, you should install a four-digit patch in a new, clean directory. The basic steps are as follows:
Re-install the base release in a new directory.
Install the patch release host package.
Install the patch release target package.
Install add-ons: host first, then target.
Using 7.3.0.7 as an example, you would install the packages as follows:
Install the Connext 7.3.0 host package for your platform:
rti_connext_dds-7.3.0-pro-host-<host_platform>.[run|exe]
Install the 7.3.0.7 host patch package:
rti_connext_dds-7.3.0.7-pro-host-<host_platform>.rtipkg
Install the 7.3.0.7 target package:
rti_connext_dds-7.3.0.7-pro-target-<architecture>.rtipkg
(Optional) Install other add-ons that you might be using. For example:
rti_security_plugins-7.3.0.7-host-openssl-3.0-<host_platform>.rtipkg, followed by rti_security_plugins-7.3.0.7-target-openssl-3.0-<architecture>.rtipkg
rti_observability-7.3.0.7-host-<host_platform>.rtipkg
rti_dotnet_support-7.3.0.7.rtipkg
rti_cloud_discovery_service-7.3.0.7-host-<host_platform>.rtipkg, followed by rti_cloud_discovery_service-7.3.0.7-target-<architecture>.rtipkg
Attention
If the package has “target” in its name, you must install its corresponding host package first. Never install only a target package in any release. If there are public header file changes, never mix and match release versions in the same installation directory.
The following sections provide advanced information on why it is critical to follow these patch installation instructions for patches that contain public header file changes.
2.2.2. Public Header File Changes
Most patch releases contain public header file changes that are incompatible with previous releases. You should install patches that contain public header file changes into a new directory (not on top of your current installation). You shouldn’t mix and match packages or products from other releases. The release notes supplement that comes with the patch will tell you whether the patch contains public header file changes.
For example, if you are upgrading to 7.3.0.y and you are using Security Plugins with OpenSSL (and the patch contains public header file changes), do not continue using Security Plugins with OpenSSL from 7.3.0 or a previous 7.3.0.x release, but install the Security Plugins package from 7.3.0.y (for example, rti_security_plugins-7.3.0.y-host-openssl-3.0-<host_platform>.rtipkg).
This rule applies to all Connext products supported in 7.3.0, whether or not they are already included in your patch. (If they aren’t, you can request them.)
2.2.3. Special Backup of RTI Libraries
When installing a host patch package, commonly used libraries for RTI Tools and
Infrastructure Services are updated to the patch version in
<NDDSHOME>/resources/app/lib/<architecture>. Since patches do not
always include all products, the RTI package installer creates a backup folder
to retain the base version of the libraries alongside the patched versions.
This ensures that both patched and unpatched products can use the correct
version of the Connext libraries. The backup copy of the base libraries is
stored in the <NDDSHOME>/resources/app/lib/<architecture>/<current_installed_version>
directory when a patch is installed.
When installing a new RTI target package that overwrites a given library in the
<NDDSHOME>/lib/<architecture> directory, the installer will copy the
library from the <NDDSHOME>/lib/<architecture> directory to the
<NDDSHOME>/lib/<architecture>/<current_installed_version> directory.
This copy will serve as a backup.
For example:
If you install host patch version 7.3.0.7, the overwritten base 7.3.0 libraries used by non-patched Tools and Infrastructure Services will be copied into the following directory before the 7.3.0.7 host patch libraries are installed: <NDDSHOME>/resources/app/lib/<architecture>/7.3.0.
If you install patch version 7.3.0.7 to the RTI Core Libraries for x64Win64VS2017, your overwritten core 7.3.0 libraries will be copied into the following directory before the 7.3.0.7 libraries are installed: <NDDSHOME>/lib/x64Win64VS2017/7.3.0.
If you install another patch later, before the 7.3.0.7 libraries are overwritten, then the 7.3.0.7 libraries will be copied into <NDDSHOME>/lib/x64Win64VS2017/7.3.0.7.
2.2.4. RTI Tools and the Backup Directory
RTI Tools commonly rely on the backup directory, so it is important to make sure its contents are correct, especially when you are using add-on products, such as Security Plugins. To ensure the backup contents are correct, you must follow the instructions in General Patch Installation Steps, which involve first installing the base version, such as 7.3.0.
Installing the base version first ensures that when RTI Tools (such as RTI Admin Console and RTI System Designer) are not part of the patch release (they usually are not), they keep using the base libraries they are built with instead of the patched libraries. You will receive an error otherwise.
The error is caused by the RTI tool not finding the base libraries. The RTI tool will look for the base libraries in the backup directory, such as <NDDSHOME>/resource/app/lib/<architecture>/7.3.0. But that backup directory either will not exist or will not contain all of the necessary base libraries if you didn’t install the base version packages first. The tool will then look for the library in the patched directory. But if the patched library uses a function that is not implemented in the core library in the backup directory, an error occurs.