Vixen
dd8b0a81
csharp
public static class ProjectPlugins

Contributes a project's plugins' importers, so the CLI claims what the editor claims.

Read the guide page for this →

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 Folder

    The 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