I recently had trouble to run the existing editor plugin with the 3.5.0 release.
The reason seems to be that all the AGS .net assemblies were changed to strong names. This is a breaking change, as the plugin compiled with an existing assembly (e.g. the plugin references AGS.Types) with a weak name is not compatible with the new one compiled with a strong name
It was to get a namespace for the settings class, to differentiate between builds which are (effectively) portable and the actually releases where settings need to persist between versions. As long as the plug-in isn't mixed assembly, you can retrospectively sign it by decompiling and recompiling with a generated key.
Alright, this looks like another consequence that was not thought of beforehand. There is a number of editor plugins, Speech Center is one of the most popular ones, and there is at least one other I know - Rulaman's Font Editor. Does this means we need plugin author to come by and recompile the plugin? (idk what are other editor plugins in use)I think the main restriction is that a signed assembly cannot load an unsigned one, although to permit access to internals for the unit tests I had permit access via the public key. For an external interface though, I would need to test it. Is there a plugin stub somewhere that I can test with? We could look at using something else though, the main benefit of this was that it was built-in, so for a Mono build it was likely to be well tested.
From now on writing editor plugin was relatively simple, now if someone does that will have to know to do this signing too. And also, does not this mean that there should be two version of each plugin from now on - for old Editor and for the new one?
May there be an alternate solution to signing, like using some third-party settings library instead of Microsoft's one?I think the problems are generally in terms of deployment, where the program is delivered using ClickOnce and installed per user. In that case you do end up with multiple installations, so using a strongname would override where the settings are loaded from. So the main purpose of the library is to just override the settings path (manually), so that you can store settings where you like.
I remember you've mentioned this library (https://github.com/taxophobia/CustomSettingsProvider), will it work without strongname? The strongname issue is mentioned in its readme, but it's not stated explicitly.
For an external interface though, I would need to test it. Is there a plugin stub somewhere that I can test with?
Signing the plugin will not solve the issue. The problem is that the plugin was compiled with a reference to an AGS.Types assembly that didn't have a strong name. With AGS.Types now having a strong name it is not backwards compatible with previous versions. When AGS tries to load the plugin, it can't since the plugin is missing one of the references.
So indeed the consequence is that all plugins will need to be recompiled with the new library reference.
Signing the plugin will not solve the issue. The problem is that the plugin was compiled with a reference to an AGS.Types assembly that didn't have a strong name. With AGS.Types now having a strong name it is not backwards compatible with previous versions. When AGS tries to load the plugin, it can't since the plugin is missing one of the references.
So indeed the consequence is that all plugins will need to be recompiled with the new library reference.
Do you also see an issue referencing a specific version of irrKlang? It looks like there are some options to redirect reference loading, but with (what I think is) the newest version of the SpeechCenter plugin the first error I get is trying to load irrKlang rather than AGS.Types.
Just to confirm, is this (http://www.adventuregamestudio.co.uk/forums/index.php?topic=45622.0) the latest version?
I think the problems are generally in terms of deployment, where the program is delivered using ClickOnce and installed per user. In that case you do end up with multiple installations, so using a strongname would override where the settings are loaded from. So the main purpose of the library is to just override the settings path (manually), so that you can store settings where you like.
Does the strongname signing give any other benefit for AGS rather than making settings system have consistent path?List of benefits here: https://stackoverflow.com/questions/2354129/why-use-strong-named-assemblies
Maybe it is best to open an issue on GitHub, since future changes to the plug-in system are probably determined by the choice made here.Could you also elaborate a little on this, what changes to plugin system will be determined by this (or how)? Just want to be sure that I understand the situation well.
Am I correct guessing that this will substitute the unsigned AGS.Types demanded by plugin with signed one?Yes, to test this I made the relevant section of PluginsComponents.cs look like this:
Could you also elaborate a little on this, what changes to plugin system will be determined by this (or how)? Just want to be sure that I understand the situation well.The main restriction is that a strongnamed assembly cannot reference (i.e. build against) an assembly that isn't strongnamed (this is requested as a 'full' bind), but using Assembly.LoadFile is treated differently (this is requested as a 'partial' bind). The loading assembly is permitted to modify the loading behaviour since the code for this is in the signed part (so the handling is in the Editor, not in the plug-in).