Class 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.
Inherited Members
Namespace: Serenity.Global.Application.References
Assembly: Serenity.Global.Application.dll
Syntax
public static class CollectionSettingsSelection
Methods
WithoutShadowedTwins<T>(IReadOnlyList<T>, Func<T, string>, out IReadOnlyList<string>)
Returns candidates without the shipped members an adopted twin shadows.
Declaration
public static IReadOnlyList<T> WithoutShadowedTwins<T>(IReadOnlyList<T> candidates, Func<T, string> idOf, out IReadOnlyList<string> shadowedIds)
Parameters
| Type | Name | Description |
|---|---|---|
| IReadOnlyList<T> | candidates | Every candidate a collection lookup found, in load order. |
| Func<T, string> | idOf | The candidate's |
| IReadOnlyList<string> | shadowedIds | The dropped candidates' ids, in the same order, duplicates included. |
Returns
| Type | Description |
|---|---|
| IReadOnlyList<T> | The kept candidates, input order preserved; never null. |
Type Parameters
| Name | Description |
|---|---|
| T |
Remarks
A candidate S is dropped only when idOf(S) is non-empty, its renamed form
differs from itself (ordinal), and some candidate carries that renamed id. The self-difference
check is load-bearing: RenamedId(string) is idempotent, so without it
every adopted X_Project would find itself and delete itself. Idempotence also means a
chain of twins cannot exist, so one pass is enough.
Null or empty ids are kept — an identity defect belongs to validation, not to a load-time drop.
Duplicate ids are not deduped here; that is the caller's own rule (e.g.
KeepOneDefinitionPerMenuId), applied after this one.