Marketplace Packaging and Extension Lifecycle📋

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.

The marketplace is a catalogue and acquisition experience over compatible extension packages. Its first transport is NuGet feeds, including public and private sources. Local artifacts and Git builds enter the same extension-resolution and activation process.

Commercial terms, if any, belong to the publisher's package information. This proposal does not define a checkout or billing system.

Package information📋

A catalogue entry must identify publisher, package/version, description, contribution families, compatibility requirements, dependencies and acquisition source. Package contents include declared assemblies, dependency metadata, required assets and configuration/migration contributions.

The catalogue must distinguish package metadata claims from verified compatibility evidence. A cached catalogue entry cannot establish that a package is already active in an instance.

Local import records artifact identity and provenance. A Git import records the selected revision or source snapshot and toolchain, then produces an equivalent candidate package. Imported files do not bypass compatibility checks.

NuGet dependency resolution is an existing platform mechanism to integrate; the active instance records the resolved package graph and its own Diem contract checks. NuGet dependency resolution↗ (ouvre dans une nouvelle fenêtre).

Proposed lifecycle📋

The host must name the target instance or track before activation. Acquiring a shared package cache entry does not update all instances which use another version of that package.

Dependency and contribution checks📋

Resolution must detect missing packages, unsupported versions and dependency cycles. Contribution validation checks contract versions, stable ownership, required services, renderer implementations and frontend assets.

An extension may register a new contract family that another package implements. The resolved ordering must make that contract available before validating and activating its dependent contributions.

The package description must declare whether activation requires an application build, host restart or supported dynamic registration. Each route must produce an observable result.

Upgrades📋

An upgrade plan compares current and candidate package graphs, contribution contracts, configuration and schema needs. It identifies dependent components affected by changes.

If checks fail, the current active selection remains identifiable. If migration or activation partly completes, the operation record states the actual result and available recovery. An older package is not a universal data rollback mechanism.

Version selections used for a release are recorded. A catalogue's “latest” label must not silently mutate an existing release.

Disable, remove and retain📋

Disabling contributions, uninstalling package artifacts and deleting package-owned records are separate operations. The host must first identify dependent packages, configured components and retained data.

Removal either succeeds under the declared policy or reports the dependencies that prevent it. Data retention is the default unless a separate authorized operation requests deletion. Removing a shared cached artifact must not break another active instance.

Package execution follows the configured trust and isolation policy. Dependency resolution and assembly loading alone do not provide an isolation boundary for arbitrary third-party code.

Acceptance📋

MARKET-01: NuGet, local artifact and Git-build routes produce inspectable identities and the same compatibility decisions for equivalent packages.

MARKET-02: a package adds frontend, admin and Lab contributions only in the selected instance after successful activation.

MARKET-03: unavailable dependencies, cycles and missing assets block activation with actionable diagnostics.

MARKET-04: updates and removal account for dependents, preserve declared retained data and leave other instances' active selections unchanged.

See Extension Contracts and Compatibility for contribution semantics and Content, Data and Promotion for module-specific data handling.

Previous: Reference Scenario and Acceptance Criteria · Series index · Section index