Contingent on the technologies being used by the OpenExchange developer, there are several methods that can be utilised to detect the SDL Studio product version (e.g. 2009 or 2011) or the specific studio version (e.g. SP1, SP2).  NOTE:  Studio 2009 and Studio 2011 have different upgrade codes to enable them to both be installed on the same machine.

1. MSI Installer Interrogation

1.1. If you are using MSI installers use the “Upgrade Table” and the FindRelatedProducts action to list of SDL product upgrade codes to determine the product codes of installed products.

1.2. To detect where Studio is installed from an MSI installer, use the following registry searches;

1.2.1. HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\<product code>\ InstallLocation if this is a 32-bit machine or

1.2.2. HKLM\SOFTWARE\Wow3264Node\Microsoft\Windows\CurrentVersion\Uninstall\<product code>\ InstallLocation if this is a 64-bit machine.

2. Windows API Interrogation

If you are using a programming language that has access to the Windows API (C++, C#, Nullsoft installer etc) you can use MSIEnumProducts(), passing the upgrade code you are interested in to get the product codes back or MSIGetProductInfo() if  you are trying to detect a particular product code/version.

3. Registry Interrogation

3.1. If you do not have access to the Windows API via your programming language, you can derive the Studio version from following registry keys.  

3.2. HKLM/Software/SDL/Studio1 to detect Studio 2009

3.3. HKLM/Software/SDL/Studio2 to detect Studio 2011

(NOTE: Above does not allow you to detect the actual Studio version (e.g. 2001 RC1)

3.4. Specific product codes can be checked for under; HKLM\SOFTWARE\[Wow3264Node\]Microsoft\Windows\CurrentVersion\Uninstall\<product code>

(NOTE: Registry interrogation can be difficult to rely on due to 32-/64-bit registry redirection.  Also, there are no guarantees this approach will continue to work with future Windows versions)

4. Licensing API Query

For Studio 2011 you can detect the specific Studio license version, using the public

“Sdl.TranslationStudioAutomation.Licensing” API, e.g.

public static bool IsLicensed

public static StudioEdition CurrentEdition

public static bool IsFeatureLicensed(StudioFeature studioFeature)

Thanks for the details, Ian!

However, we still have some questions and suggestions to improve our installation process.

1. Query installation path

Our installer needs to know, where SDL Trados Studio is installed. For this, we need to go to registry and query that information. Unfortunately, as you recommend, we have to use uninstall information from registry key

HKLM\SOFTWARE\[Wow3264Node\]Microsoft\Windows\CurrentVersion\Uninstall\<product code>

Everytime a new Service Pack for Studio is delivered, we also have to update our setup application, to query the information with the new product code. This also means that we have to resubmit for approval etc.

It would be great, if you could add the install path information to HKLM\Software\SDL\StudioX

This way, we would not have to change the installer and creating a new package for every new SP.

2. Deploying plugins

In Studio 2009 it was possible to install sdlfiletypes and corresponding dlls in Studio’s installation directory. This had its charm, because this plugin is available for all users who work on this machine. Since Studio 2011, deploying plugins changed. AFAIK, we can only deploy to %LOCALAPPDATA%\SDL\SDL Trados Studio\10\Plugins\Packages. This is restricted to only the current user. There’s no possibility to deploy it in a central directory or to “All users”. So other users have to copy sdlplugin-package to their own %LOCALAPPDATA% directory, by hand. Is it possible (now or in future) to put this package back to Studio’s installation directory? What’s your recommendation?

3. plugin configuration

Our plugin has some configuration settings and its configuration file, where customers are able to change plugin’s behavior. There is an app.config file, delivered with the dll and this works fine in Studio 2009, because dll and config are located in Studio’s installation directory. Because sdlplugin-package is unzipped to unpacked directory and if studio is closed files are deleted again, there’s no possibility to keep configuration changes alive. What’s your recommendation doing this? Where can we securly place a config file?

Thanks for your feedback!

1. Query installation path

Our installer needs to know, where SDL Trados Studio is installed. For this, we need to go to registry and query that information. Unfortunately, as you recommend, we have to use uninstall information from registry key

HKLM\SOFTWARE\[Wow3264Node\]Microsoft\Windows\CurrentVersion\Uninstall\<product code>

Every time a new Service Pack for Studio is delivered, we also have to update our setup application, to query the information with the new product code. This also means that we have to resubmit for approval etc.  It would be great, if you could add the install path information to HKLM\Software\SDL\StudioX.  This way, we would not have to change the installer and creating a new package for every new SP.

SDL: Adding a registry entry with the Studio install path is going to be added to the product backlog and will be implemented at some point in the future.  The registry entry is not finalised but will probably be:  HKEY_LOCAL_MACHINE \SOFTWARE\SDL\Studio2 – value called InstallLocation

2. Deploying plugins

In Studio 2009 it was possible to install sdlfiletypes and corresponding dlls in Studio’s installation directory. This had its charm, because this plugin is available for all users who work on this machine. Since Studio 2011, deploying plugins changed. AFAIK, we can only deploy to %LOCALAPPDATA%\SDL\SDL Trados Studio\10\Plugins\Packages. This is restricted to only the current user. There’s no possibility to deploy it in a central directory or to “All users”. So other users have to copy sdlplugin-package to their own %LOCALAPPDATA% directory, by hand. Is it possible (now or in future) to put this package back to Studio’s installation directory? What’s your recommendation?

SDL: In Studio 2009, the Studio system file type definition files were all installed to the <install-folder>\FileTypes folder. Any third party file type definition files placed here would automatically be picked up by Studio. Studio 2011 no longer uses file type definition files so this unofficial workaround can no longer be used.

In Windows 7, most users do not have write access to the all user 'Common Application Data' folder. By default, only admin users have the necessary permissions to add or change files here. This would prevent Studio from unpacking the plug-in packages without admin permissions.

There are currently no plans to move the Studio OpenExchange plug-in folders.  The best practice here is actually for the vendor to provide an installer with every plug-in that automates copying the package to the appropriate location, so the users don't have to do this by hand (which is indeed cumbersome). With future versions of Studio, we'll also be looking at automating this from the Studio side (install plug-in from Studio).

3. Plugin configuration

Our plugin has some configuration settings and its configuration file, where customers are able to change plugin’s behavior. There is an app.config file, delivered with the dll and this works fine in Studio 2009, because dll and config are located in Studio’s installation directory. Because sdlplugin-package is unzipped to unpacked directory and if studio is closed files are deleted again, there’s no possibility to keep configuration changes alive. What’s your recommendation doing this? Where can we securly place a config file?

SDL: Ideally, the plug-in installer should install any config files to the plug-in’s own local application data folder.

i.e. [LocalApplicationData]\<company-name>\<product-name>\app.config

Ian Davies  |  Senior Product Manager | SDL | Language Technologies Division |                          +44 7826843819