Studio 2019 has arrived and it brings with it some nice features on the surface, and some important improvements under the hood… but it also brings with it a lot more upgrades than just Studio, and I don’t just mean MultiTerm! The SDL AppStore is one of the unique benefits you get when you work on the SDL technology stack and there are hundreds of apps available that can provide additional resources, custom filetypes, file converters, productivity enhancements, manuals, etc. When you upgrade your version of Studio you are also going to have to upgrade your apps. Many of the apps are maintained by the SDL Community team and these have all been upgraded ready for use in Studio 2019, but the majority have been created and maintained by others. I’ve written this article to explain what you need to look out for as a user of SDL Trados Studio or MultiTerm, and also as a reference guide for the developers who might have missed the important information that was sent out to help them with the process.
You can’t install an older app into Studio 2019
First of all, if you’ve got your sdlplugin files all stored somewhere safe for Studio 2017 or earlier you need to know that you can’t use these in Studio 2019. Now, if you try to install these old ones you squirrelled away you’ll probably see something like this which makes you think it should as Studio 2019 is not greyed out:
The reason for this is that the sdlplugin itself contains a manifest file that sets the minimum version to be used and the maximum version to be used. The maximum version was broken and nobody noticed until now! Those of you who subscribe to the RSS feed and get notified of updates probably noticed that all the SDL Community apps for 2017 were updated a little while ago so that they cannot be installed in 2019. If you try the latest 2017 versions you’ll see that “SDL Studio 2019” is greyed out so you can’t even try. The technical reason for them not working in 2019 is explained below in the developer section if you’re interested… but I just wanted to say that this wasn’t done to deliberately make life harder or to force upgrades! Unfortunately if you didn’t see the updated plugins you might experience the problem of being allowed to install an older 2017 app into 2019 and then it will only cause an error when Studio starts. So if you have Studio 2019 make sure that you check in the appstore that there is a version of your favourite apps and only use that.
Developers who have upgraded their apps will have a note at the top in the app overview when they post the upgrade and you’ll be able to see the supported products listed on the right. You do have to have a valid Studio licence in your account for the appropriate version to be able to download them but as long as you have this you should be good to go! If your favourite app hasn’t been upgraded yet then scroll down a little in the app record in the appstore and you’ll find the developer contact information there. In this case you’re referred to the appstore forums in the SDL Community because this is the contact details for the SDL Community team. But most other developers provide their contact email, sometimes even a telephone mumber, so you can get in touch and ask whether they will be updating their apps or not:
How to update the apps… for developers!
Existing Studio 2017 or 2015 plugins
If you have created plugins for these versions of Studio we are recommending that you update them to ensure they include a maxversion attribute in the plugin manifest. If you don’t do this then any user who installs Studio 2019 will be incorrectly offerred the opportunity to install your current plugins as shown in the image on the left below and described above:
Adding this attribute will ensure that Studio 2019 is greyed out as shown above on the right. There are a few steps required to achieve this as we have updated the Sdl.Core.PluginFramework.Build to use this attribute correctly. You can find detailed instructions in a wiki article in the Language Developers wiki in the SDL Community.
Upgrading your plugins to Studio 2019
First of all you will need a copy of SDL Trados Studio 2019 and SDL can help with a development version if you need it. Just ask in the developer forums if you don’t know how to get this. Once you’re ready the process is straightforward and you can upgrade your plugins to support Studio 2019 using an extension available for Microsoft Visual Studio 2017. This is available through the Visual Studio extensions menu or by downloading from the Microsoft Marketplace:
The SDL Community team have also created a set of instructions, and a video, available in a wiki article in the Language Developers wiki in the SDL Community.
Why is all of this necessary?
The Studio APIs are versioned based on the changes we’ve introduced. Some of the APIs have changes in Studio 2019 and some don’t but all of them, except FileTypeSupport, were updated to .Net 4.7.1. This introduces a breaking change and any developer who tries to compile a .Net 4.5.2 plugin will receive an error. This is because the .Net framework is backward compatible but not forward compatible.
Having at least one breaking change in the APIs meant we had to highlight this with a version change, hence the Studio API assembly version was changed. This in turn means rebuilding and publishing a new plugin so we built a Visual Studio extension that automatically upgrades a Studio 2017 plugin codebase to a Studio 2019 plugin codebase as explained above.
I hope this is clear, and helpful, but if you have any questions on this please post your questions in the Language Developers forum in the SDL Community where we’ll be happy to help.
I’m wondering what exactly the “The maximum version was broken” means…
I checked a bunch of plugins I have on my disk and actually none of them has the maximum version mentioned in the manifest XML! So does it mean that what was broken was actually some SDL tool/process/something which was supposed to include the maxversion attribute to the manifest?
You’re spot on Evzen. The plugin framework removed the maxversion attribute from a plugin when it was built in visual studio, so even if you set it the final version omitted it.
Okay, understood.
The more I think about the attribute, the more I believe it’s not actually a good concept anyway ;-).
The thing is that it’s basically impossible to know at the time of building the plugin what will be the max Studio version where the plugin will work. As a consequence, the entire idea is “reactive”, i.e. one can only retroactively react to the compatibility changes in Studio only AFTER the changes in Studio happen and still has to
– either not use the maxversion or set it to something big in a believe that the plugin will work… and then if an incompatibility arises, build a special version of the plugin for the OLD version just to prevent it from installing into newer Studio (just as it happened now in Studio 2019)
– or be “conservative” and set the maxversion the same as minversion… and then create new plugin version for each new Studio version, just because of the conservative setting
Either way is just annoying for both the developers and the users… and is not intuitive at all.
I think we all agree with you Evzen.