public interface IContributionScannerReads a loaded assembly's declarations and registers what it finds.
Remarks
Doc 36 § D3, and the seam that makes the attributes symmetric. A plugin's assembly and a project's script assembly are the same kind of thing — one discrete assembly the editor has just loaded — and both should get the same treatment from [EditorMenu], [CustomInspector], [CustomDrawer] and [EditorTool]. Before this, the first worked only in a script and the other three nowhere, which is an asymmetry nobody could have predicted from the attributes.
⚠ An interface here and the implementation elsewhere, and that is the whole reason it exists. The attributes name CustomInspector, DrawerRegistry and SceneTool — types in Vixen.Editor.Inspector and Vixen.Editor.SceneView — and this assembly must not reference either. That is P2's rule: a method per contribution kind on PluginContext would put the whole kind list in the contract assembly and make it reference every feature assembly that owns one, which is F2's problem one layer down. What crosses this boundary is a PluginContext and an Assembly, and neither is a feature type.
⚠ Everything a scanner registers goes through the context it is handed, so it is in the plugin's own registration scope and goes away when the plugin does. A scanner that registered anywhere else would be the one leak this whole arrangement is built to prevent.
Methods (1)
void Scan(PluginContext context, Assembly assembly)Registers whatever an assembly declares.
Used by (2)
- DeclaredContributionsVixen.Editor.App
- PluginHostVixen.Editor.Plugin