Develop a CloudGrange module
Modules are trusted, signed, in-process components. You build one against the contracts in the .NET SDK, declare its behavior in a manifest, and the platform hosts and lifecycle-manages it. The reference implementation is cloudgrange-module-example.
CloudGrange is in preview, not GA. The module contract may change during preview. Signing is planned but not yet implemented. See current product and release status.
The contract
A module implements the SDK's ICloudGrangeModule and receives an IModuleContext at runtime. The manifest owns the module's stable identity and declares everything the platform needs to load and run it safely:
- Stable module ID and version, plus compatible Core/API/SDK version ranges
- Dependency graph (cyclic dependencies and unknown permission wildcards are rejected)
- Publisher, signature, and provenance
- Schema and migrations
- Exported capabilities, permissions, and configuration schema
- UI contributions (navigation slots), job types, payload hashes, and health checks
Version-range validation runs before any code loads. Portal contributions are compiled into a signed, compatible portal bundle with availability supplied by the API — modules do not inject arbitrary remote JavaScript.
Data and cross-module access
Each module owns its own schema. Records carry immutable IDs, tenant scope, creation/update provenance, and a schema version. Mutable desired state uses revision checks; observations retain a source timestamp and freshness. Long-running writes return a platform job identifier. A module accesses another module's data only through that module's published contracts or events — never by writing another module's schema directly.
Where to start
- Clone cloudgrange-module-example and read its manifest and module class.
- Reference the cloudgrange-sdk-dotnet contracts.
- See the Hello World module reference for a concrete walkthrough of the reference module.