Skip to main content
Welcome. This site supports keyboard navigation and screen readers. Press ? at any time for keyboard shortcuts. Press [ to focus the sidebar, ] to focus the content. High-contrast themes are available via the toolbar.
serard@dev00:~/cv

Extension Contracts and Compatibility

Status: Public design proposal and product vision. This series presents Diem CMF .NET’s intended architecture and capabilities. Proposed features remain subject to implementation and validation; existing components are identified separately.

An extension package supplies one or more contributions to installed contract families. A contribution can introduce domain types, frontend implementations, admin modules, Lab services or another extension point.

DLL loading is one part of this contract. The package also needs enough metadata, dependencies and assets for the selected host and renderer to use it correctly.

Proposed contribution description

The following shape illustrates the required information without fixing a released API:

public sealed record ExtensionDescriptor(
    string PackageId,
    string Version,
    IReadOnlyList<string> Dependencies,
    IReadOnlyList<ContributionDescriptor> Contributions);

public sealed record ContributionDescriptor(
    string ContributionId,
    string ContractId,
    string ContractVersion,
    string ImplementationReference,
    IReadOnlyList<string> RequiredCapabilities);

Production packaging must replace shorthand dependency strings with the distribution provider's versioned identity and resolution model. The release records the resolved result.

Contribution identifiers must have stable ownership. Conflicting registrations cannot be resolved by load order without an explicit replacement policy.

Compose packages and instances separately

A Catalogue package can depend on Media. Product Card can expose a media slot implemented by an installed Media component. The Product editor can reuse Media's picker. A Lab storage contribution can realize the media storage dependency.

These relationships form two structures: the package dependency graph and the configured contribution-instance graph. Declared recursive component types do not justify a cyclic package dependency or an infinitely expanding instance tree.

An extension may introduce a new contribution contract. Another extension can implement that contract after compatibility resolution. The core registry does not need a new switch statement for every application-specific family.

Assembly and asset boundaries

Host-shared contract assemblies must retain compatible type identity. Implementation dependencies can use appropriate load contexts and resolution rules. The host checks required runtime/framework references and native dependencies before activation.

A frontend contribution declares its asset and renderer needs. Razor/Blazor libraries may include resources alongside compiled types; static renderers need their own compatible implementation or export path. Loading a DLL does not automatically install its routes, assets and generated client output.

Microsoft documents plugin dependency loading (ouvre dans une nouvelle fenêtre) and Razor class-library assets (ouvre dans une nouvelle fenêtre). These are integration foundations to validate with the chosen .NET 11 toolchain.

Assembly load contexts resolve dependency groups; they are not an operating-system security boundary. Where a deployment needs execution isolation, the extension host must use an appropriate process/container boundary and declared capabilities.

Activation and replacement

Compatibility checks cover contract versions, selected .NET toolchain, renderers, assets, service dependencies and data/schema requirements.

An extension may activate at host startup, after an application rebuild or through a supported dynamic registration path. It must report which route it supports. Pluggability does not promise universal replacement of live types without restarting.

If validation fails, the extension remains acquired but inactive, with attributable diagnostics. Upgrading one branch's selection must not silently replace the package set active in another instance.

Data and configuration contributions

An extension declares editable settings, fixed constraints and defaults. It also declares whether its content/data can be promoted and which merge implementation performs that operation.

A contributed admin form edits permitted configuration. Lab operations consume the same resolved values. Merger implementation and permission to invoke it are distinct capabilities.

Acceptance

EXT-01: one package contributes frontend, admin and Lab capabilities through compatible contracts.

EXT-02: a dependent extension composes supplied types and components, including a newly introduced contribution family.

EXT-03: cyclic dependencies, duplicate contribution ownership, missing assets and incompatible contracts fail before activation.

EXT-04: package acquisition, activation and per-instance selection remain distinct, and required rebuild/restart behavior is visible.

Previous: Workspaces, IDEs and Hot Reload · Next: Content, Data and Promotion · Series index · Section index

⬇ Download