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:
Assembly CurrentDomain_AssemblyResolve(object sender, ResolveEventArgs args)
{
AssemblyName assembly
= new AssemblyName
(args
.Name);
if (assembly.Name == "AGS.Types")
{
return typeof(BuildTargetsInfo
).Assembly; }
return null;
}
private void LoadEditorPluginIntoMemory(string fileName)
{
AppDomain
.CurrentDomain.AssemblyResolve += new ResolveEventHandler
(CurrentDomain_AssemblyResolve
);
try
{
EditorPlugin plugin
= new EditorPlugin
(fileName, _pluginEditorController
); _editorPlugins.Add(plugin);
}
catch (AGSEditorException ex)
{
_guiController.ShowMessage("There was an error loading plugin '" + fileName + "'." + Environment.NewLine + Environment.NewLine + ex.Message, MessageBoxIcon.Warning);
}
catch (Exception ex)
{
_guiController.ShowMessage("There was an error loading plugin '" + fileName + "'." + Environment.NewLine + Environment.NewLine + ex.ToString(), MessageBoxIcon.Warning);
}
}
So rather than be an exception you get the chance to load something else, and in this example the only check performed is the name of the requested assembly. What is returned is the Assembly reference for the actual AGS.Types that was built (in this case, the one that is strongnamed).
There is probably a better way to reference the assembly directly, but this:
return typeof(BuildTargetsInfo
).Assembly
just returns the
Assembly instance of AGS.Types (the strongnamed one), because that is the assembly where BuildTargetsInfo is located.
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).
I guess the main thing is, at the moment there isn't really any separation of plug-in and Editor, since there is no piece in-between to broker what is available in the Editor and what is requested in the plug-in. I don't know if anyone had plans to change it, but if it would stop using Assembly.LoadFile then however the separation is implemented would also have to be happy with plug-ins requesting signed and unsigned assemblies. I would imagine such a system would probably be more likely to declare and require interfaces rather than assemblies though.
Equally, this probably needs testing with the most complex plug-ins people can find. At the moment I've only started up these two plug-ins for testing, but I've not built anything for Android or actually edited a font.
