GameAssemblies

Remarks

The gap this closes. A game declares scene components of its own — [Component] beside [DataContract] — and Vixen.Engine.Generators emits a [ModuleInitializer] that tells SceneComponentRegistry and the type registry about them. That initializer runs when the assembly is first touched, and in a build tool that never references the game, nothing ever touches it. So a level carrying the game's own !SpawnPoint compiled against a registry that had never heard of one, and the build failed with "nothing in this build claims the name" — about a type that is right there in the project being built.

⚠ Loading is not enough; the module constructor has to be run. The CLR runs a module initializer lazily, at the first access to a type in that module, and an assembly loaded and never otherwise used has had no such access. RunModuleConstructor is what makes the load mean something — it is idempotent, so a module that has already run is not run twice.

Only ever additive. Nothing here is called for its return value: the effect is the registrations the initializers perform. A path that does not exist is skipped rather than failing the build, because the first build of a new project imports its assets before the compiler has produced anything to load — which is exactly the ordering Vixen.Sdk.targets documents, and why the content-build pass after Build is the one that carries the assembly.

Methods (1)

• public static int Load(IEnumerable<string> paths, Action<string>? report = null)

  Loads each assembly and everything it references, running every module initializer.

Used by (1)

• VixenCommandVixen.Cli