public static class ProjectPluginsContributes a project's plugins' importers, so the CLI claims what the editor claims.
Remarks
The gap this closes, which is GameAssemblies' one door along. BuiltInImporters.Create() folds in Default, and in this process nothing had ever put anything in it: PluginHost has no caller outside EditorApplication. So an asset a plugin's importer claims was imported by the editor and fell through to RawImporter in a command-line content build — succeeding, as a chunk called Blob that no typed reader resolves, with no diagnostic. Silence is the failure.
⚠ Importers only, and no shell. A plugin also registers commands, panels and menu items, and a command-line tool has nowhere to put any of them — so this is PluginDiscovery for the files and PluginImporters for the load, and not PluginHost, which needs an EditorShell to activate anything against. It is the same importer-only load a compiler worker performs, pointed at the same folder the editor scans.
⚠ The project's Plugins/ folder and deliberately not the user's. The editor scans both, project first, so that a plugin checked into a repository beats the copy somebody installed globally. A content build has a stronger requirement than precedence: two machines with the same checkout have to produce the same bytes, and a build that imported an asset differently because of what one of them happened to have installed is the very divergence this file exists to end. So a plugin a project's content depends on is one the project carries — and the user root cannot be spelled from here anyway without guessing the editor's own organisation and application qualifier.
⚠ A plugin that will not load is reported and not fatal, on GameAssemblies' terms — a project with one broken plugin still has a build worth finishing. What it must not be is quiet, because the asset it claimed imports as bytes and exits zero.
⚠ The scope has to be disposed before a second Load in one process. Nothing is cached — PluginImporters.Load makes a fresh load context per call and says plainly why — so loading a plugin twice would give this process two types under one [DataContract] alias, which TypeRegistry refuses. One command, one load.
Fields and properties (1)
public const string FolderThe folder under a project root that holds its plugins, as the editor names it.
Methods (1)
public static IDisposable Load(Project project, Action<string>? report = null)Loads every importer the project's plugins declare and contributes it.
Used by (2)
- ImportRunnerVixen.Cli
- ProjectPluginTestsVixen.Cli.Tests