Extensions and Marketplace
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 proposed marketplace makes Diem capabilities discoverable and reusable. It distributes extensions that can contribute to the public front, the administration application and the Lab.
An extension is a package with a declared contract and dependencies. It may contain several DLLs and frontend assets. Downloading it and activating its capabilities are separate steps.
One extension can cover several experiences
Consider a proposed Media extension:
| Surface | Contribution |
|---|---|
| Model | A media reference type and metadata constraints |
| Front | Image and gallery renderers, including supported static output |
| Admin | Upload, selection and metadata editors |
| Lab | A storage-service contribution using a compatible storage Bundle |
| Lifecycle | Declared migration and content-transfer behavior |
A Catalogue extension can depend on Media, place a media component inside Product Card and use the media picker in its Product editor. A Gallery extension may add a new arrangement that the Catalogue can use without copying Media's code.
The same mechanism can distribute nonvisual services, new administration types, generators, pipeline steps or provider integrations.
Find and inspect a package
The catalogue should explain the problem an extension solves, the contribution families it supplies, its supported Diem contracts and rendering targets, and its dependencies. Release information should distinguish verified compatibility from an author's claim.
The first distribution route uses public or private NuGet feeds. A team may also import compatible local artifacts or ask the Lab to build a Git repository. Each route must produce the same inspectable extension identity and dependency information.
Install into a selected context
The user selects the instance or development track that will receive the extension. Resolution determines the actual dependency versions and required capabilities. The preview can show new admin modules, available frontend components and proposed Lab services before release activation.
Installing a package in a branch does not silently modify every other instance using a package with the same name. Sharing package storage is different from sharing activation state.
If a static site selects a component that has only a dynamic renderer, the instance receives a capability error. If an extension needs a service that is not configured, the Lab identifies that requirement and the applicable provisioning contribution.
Upgrade and remove deliberately
An upgrade may change types, assets or schema. The instance needs an upgrade plan tied to the current version, including any module-specific data transformation.
Removal first identifies consumers and dependent packages. Disabling a contribution, uninstalling its binaries and deleting its data are distinct operations. Retained data must not disappear because an extension was temporarily disabled.
The proposed marketplace does not assume a payment model. Public and private catalogues concern discovery and distribution; commercial terms can be documented by the package publisher.
Extensibility has a contract
The promise is composability with understandable compatibility requirements. It is not that any arbitrary DLL can automatically supply a working frontend, admin and Lab integration.
See Extension Contracts and Compatibility for the required declarations and Marketplace Packaging and Extension Lifecycle for installation behavior.
Previous: Module Generation and Derived Products · Next: Diem Presenting and Developing Itself · Series index · Section index