A new version of Studio will be released soon which will have breaking changes, that means older versions of plugins are not compatible with Studio 2019. In older versions of the plugins manifest file needs to be updated with maxvalue attribute. Adding that attribute will prevent user to install an older version to Studio 2019.
Without maxversion attribute:
With maxversion attribute:
There are few steps you need to do make your plugin to support maxversion attribute:
Search for <PluginDeploymentPath> and change 15 with (14 if you are updating a 2017 plugin or 12 if you are updating a 2015 plugin)
Original: <PluginDeploymentPath>$(AppData)\SDL\SDL Trados Studio\15\Plugins</PluginDeploymentPath>
Updated : <PluginDeploymentPath>$(AppData)\SDL\SDL Trados Studio\14\Plugins</PluginDeploymentPath>
Right click -> Reload solution -> Rebuild solution.
To test if plugin is updated correctly :
If after rebuilding the solution you receive an error regarding "PluginDeploymentPath":
Please unload the solution -> open .csproj and make sure you don't have any references to Sdl.Core.PluginFramework.build besides the one you just downloaded from Nuget which points to 15.0.2 version:
ah, you've made a great wall again.
I remember when SDL updated from version 2015 to 2017.
This time, I'lll never goes to version 2019 until, I guess, year 2022.
Not exactly... we've provided a great toolset to make this easier for developers who know what they're doing. So when you do decide to upgrade it should be simple for you.
Looks easy enough, thanks for the post, Paul!
Let me make clear again.
1. PlugIns for SDL Trados Studio 2017 are not working at all at SDL Trados Studio 2019, not even recognized. Right ?
(except, when you have rebuild it Manually just like above main post)
2. PlugIns for SDL Trados Studio 2019 are not working at all at SDL Trados Studio 2017, not even recognized. Right ?
Hoon Kim yes you are right. Breaking changes means Studio is moved from .Net Framework 4.5.2 (Studio 2017) to .Net Framework 4.7 (Studio 2019) which makes the versions incompatible.
"incompatible".. that's very poignant word.
Thanks, Andrea-Melinda Ghisa !!!
What I find very irritating (and perhaps badly designed) is that some internal usage of some other .Net Framework version actually creates this terrible and VERY(!) user-UNFRIENDLY breaking change.
I'm using a gazzillion of various tools and applications, out of which I'm pretty sure MANY use .Net Framework internally, but I have never heard about required - and breaking - update due to change of used .Net Framework version.
I believe that there is something really wrong in the Studio plugins design, which creates all this mess.
I don't think it was a breaking change really... wrong choice of words since we knew this would be required a long time ago because of the updated .Net version. But there were also changes to some of the APIs that in some cases were breaking changes which cause plugins using the affected APIs to be updated too.
whatever wordings you choose
whatever updating/upgrading you do
I do not care
I think you are doing your job very well
But, In my side, the story is totally different
In short, I am feeling abandoned
I have more than hundread PlugIn items that is why
Like I said, I am not going to move to version 2019
I wasn't making any excuses Hoon Kim, I was just trying to clarify the issues so we don't have a discussion about the wrong thing. There may well be things that could have been handled better... but I'm no developer and don't know what the complexities are here that require plugins to be upgraded when the version of .NET changes.
I can't imagine why you need over 100 plugins, but I guess you use your ability to code to change the behaviour of many things to suit the way you work. Perhaps you can consolidate some of them and not have to deal with so many. The "Hoon Kim Kit" could be one plugin for many things perhaps.
The Visual Studio extensions should be available through Visual Studio soon and these do make updating easier, so we haven't abandoned anyone, but having been through around 50 updates with the team here I can imagine doing over 100 is a duanting and undesirable task. Perhaps you could write a small utility to automate it once the extensions are available?
Go to SDL AppStore
Count the total number of PlugIns
Not for all but for 'SDL Trados Studio' only
I can see 235 items.
Now, you Have To see the sentence you wrote;
"I can't imagine why you need over 235 plugins.."
No more to say.
Hi Evzen Polenka , I spoke to the team this morning and have a better explanation of why we have to do this.
.Net Framework 4.7.1 is able to run an application compiled against the .Net Framework 4.5.2. So it’s a valid question to ask why do I need then to upgrade my Studio plugin?
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 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. So rebuilding a single plugin is a matter of minutes. The tool is available in the Microsoft Market place or through Microsoft Visual Studio as shown in the 2019 update wiki.
I just wondering the name of team member you have spoke with.
With newer environment you have to use older codes without any kind of difficulties like this.
That is the meaning of backward compatibility.
Hi Paul et al.,
could you review your description? It is NOT working for me.
I installed Sdl.Core.PluginFramework.Build (15.0.2) from the Nuget, edited my manifest file and also my vbproj file to point to the 2017 plugins folder. Everything looks as described above. But when I compile, I am getting this:
Error: The "CreatePluginManifestTask" task could not be initialized with its input parameters.
Error: The "PluginDeploymentPath" parameter is not supported by the "CreatePluginManifestTask" task. Verify the parameter exists on the task, and it is a settable public instance property.
A step seems to be missing as my code still seems to point to the previous version of the DLL.
Tom Imhof could you please copy your .csproj in a file and attach the file?