The first part below is taken from the Eikon Help Files - Thomson Reuters Eikon Deployment, Basic Configuration for Thomson Reuters Eikon, Creating and Managing Configuration Files on a Local Drive.

Location of files on Windows 7 and Windows 8

The default location of local configuration files depends on the security group of the user installing Thomson Reuters Eikon.

Since the name of the folder containing the software package changes dynamically for each update, the path to the configuration files too is dynamic, in other words Update based dynamic folder names.

Security Group Administrator %ProgramFiles%\Thomson Reuters\Eikon\folder name of current package: X or Y or Z\Config.

Security Group Standard User %LocalAppData%\Thomson Reuters\Eikon\folder name of current package: X or Y or Z \Config.

Versions 4.0 to 4.0.22: Fixed Folder Name.

In versions 4.0.xx to 4.0.22, the configuration folder was under the folder named after the version number.

For example: %ProgramFiles%\Thomson Reuters\Eikon\4.0.22\Config

Version 4.0.23 Onwards: Dynamic Folder Names.

With versions 4.0.23 onwards, there are dynamic folders under the main Thomson Reuters\ Eikon folder, folder names: X, Y, and, Z.

X is the current package at the first installation; after an update, a new folder called Y is created in the Eikon folder.

On restarting the application, X is designed as the backup package, and Y automatically becomes the current package.

At the next update, a third folder called Z is created

On restarting the application, X is deleted, Y becomes the backup, and Z becomes the current package

At the next update, the naming convention loop begins: the new package is X, Z becomes the backup, and Y is deleted

For example: %ProgramFiles%\Thomson Reuters\Eikon\X, Y, Z\ Config

Note: Local configuration files are automatically moved to the new location after the upgrade.

How does this affect AdfinX, DEX2, RhistoryAPI etc? Other folders and files are also updated, for example the Bin folder, which contains all the AdfinX and other API dlls. So there will be a Bin folder in an X, Y or Z in;

Security Group - Administrator %ProgramFiles%\Thomson Reuters\Eikon\folder name of current package: X or Y or Z\Bin

Security Group - Standard User %LocalAppData%\Thomson Reuters\Eikon\folder name of current package: X or Y or Z \Bin

So, what is the effect of this with my Excel for Eikon VBA API calls? With VBA users in Excel when the file containing the references to the dlls is opened, at startup the path of the addon is obtained and set as the default path. If VBA doesn’t find a reference it will look into this path and update the reference accordingly.

If the Y/Bin folder is removed and X/Bin exists when the application is loaded, references to Y should be changed to X automatically.

If the Y/Bin folder still exists VBA shouldn't change the reference. But the VBA API provided to create the object (using RegfreeCom) will create the object using the correct dll in the correct folder.

Rotation will not occur if TR Excel is running. It only happens on upgrade during which time the desktop and excel will not be running so dlls will not disappear mid-session. Also, deletion cannot occur if a dll is loaded. The apps will implement a reading of EikonRoot.xml on startup to figure out the latest Eikon version folder and do dynamic loading.

So the VBA and API calls should work correctly even if the reference contained in the project is not the right one.