Namespace Serenity.Global.Application.References

Classes

AdoptedIdentityRules

The pure decision behind adoption's Id renaming: every cloned IFoundationSettings asset — a collection member, a singleton, a prefab's identity-carrying component, all alike — gets a fresh, project-local Id so it never collides with the shipped asset it was cloned from and is unambiguously a NEW asset, never a shipped one re-saved. The CreateGame editor's own adoption-time reference remapper (AdoptedReferenceRemapper) then re-points every reference the adopted set holds so this renaming never stands alone.

CollectionSettingsSelection

The rule every COLLECTION settings lookup applies once a project has adopted Serenity content: a shipped asset whose Id has an adopted twin (X beside X_Project, see RenamedId(string)) is dropped, so an adopted project installs the clone it owns instead of installing both.

Deliberately NOT the same question SingletonSettingsSelection answers. That rule asks "which of these candidates is authoritative for one slot" and decides by OWNERSHIP (the origin:project label). This one asks "is this asset the one another was cloned FROM" and decides by ID PAIRING, without consulting ownership at all: a clone that lost its label would otherwise silently reinstate the duplicate, and the label query costs a second asset round-trip at every call site.

Engine-agnostic and Unity-free — the caller decides what "Id" means for its own candidate type.

FoundationReferenceContract

One declarative row describing a single cross-asset string reference an IFoundationSettings owner type holds: which serialized property carries it, whether the stored value is a Serenity Id or Guid (or the owner's own post-rename Id, for a self-reference like UiOption.ViewId), which settings type the value must resolve against, and how the value's shape must be treated when it is read or rewritten. See FoundationReferenceContracts for the full table this feeds.

FoundationReferenceContracts

The single declarative table of every cross-asset string reference (by Serenity Id or Guid) an IFoundationSettings asset can hold, replacing what used to be several independent, hand-maintained lists: SerenityDiscoveryRegistry's curated id-contracts dump (an AI-facing report, now a projection of this table) and half of Serenity.GameSettings.Application.Validation.GameSettingWiringMap (its target-type/field lookup; the wiring-specific IsMixerParam/Summary stay its own). A future adoption-time remapper walks every row against a real asset to re-point references at adopted counterparts.

Split into five collaborators by module ownership, not partial — none carries any serialized state or Unity lifecycle, so each is a named, independently readable table: Serenity.Global.Application.References.UiReferenceContracts, Serenity.Global.Application.References.GameSettingReferenceContracts, Serenity.Global.Application.References.ViewReferenceContracts, Serenity.Global.Application.References.BootTaskReferenceContracts and Serenity.Global.Application.References.FeedbackReferenceContracts.

Enums

FoundationReferenceKind

What kind of value a FoundationReferenceContract's property stores: a Serenity Id, a Guid, or the owning asset's own Id (a self-reference, e.g. UiOption.ViewId naming the menu it is authored on).

FoundationReferenceSelector

Which run-time condition on the owning asset decides whether a FoundationReferenceContract row applies to a given element — most rows always apply, but a shared shape like UiOption stores several mutually-exclusive kinds of reference in the same fields, distinguished only by another field's value at read time.

FoundationReferenceShape

How a FoundationReferenceContract's stored value must be interpreted when it is read or rewritten — most references are a plain foreign key, but a few need special handling.