Rendering, Generation and Live Development
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.
Diem's framework experience depends on a short feedback loop, but several different mechanisms contribute to it. Model validation, source generation, compilation, hot reload, browser refresh and static generation must have separate observable outcomes.
Develop on the .NET 11 generation
The proposed runtime hosts and generated application modules target net11.0. Development begins on compatible .NET 11 previews with C# 15, ASP.NET Core 11/Blazor and EF Core 11, then follows release candidates and stable releases. Compiler-hosted tools use the target frameworks required by their host compatibility; the application runtime choice does not remove that requirement.
Microsoft's .NET 11 overview (ouvre dans une nouvelle fenêtre) describes runtime-native async, language changes and SDK/watch improvements. These are candidates to exercise in Diem's application and development workloads, not an automatic performance claim.
EF Core 11 (ouvre dans une nouvelle fenêtre) requires .NET 11 and documents expanded complex-type/JSON support with TPT/TPC inheritance. That is relevant to evaluating persistence for richer domain models. Provider support and actual mappings still require tests.
The ASP.NET Core 11 release notes (ouvre dans une nouvelle fenêtre) document Blazor changes including development hosting and component behavior. Web interfaces in C# build on Blazor's existing model; this proposal does not present C# in the browser as a new invention of .NET 11.
Track the toolchain explicitly
The implementation should pin the SDK, language settings, EF/runtime packages, compatible database providers and container images. Each preview upgrade exercises generation, rendering, migrations, package loading and the development loop.
The aim is to absorb platform changes during product development and reduce later migration work. The cost and commercial delivery date cannot be established from that intention alone.
Renderer inputs and outputs
All renderers consume agreed composition and data contracts, but advertise different capabilities.
| Capability | Hugo/SSG adapter | Dynamic .NET adapter |
|---|---|---|
| Source of page output | Versioned definitions plus selected content snapshot | Active application and authorized content/data views |
| Reusable presentation | Exported templates, partials and assets | Components, views and endpoint contributions |
| Live preview | Renderer-specific watch/rebuild cycle | Supported .NET changes and browser refresh |
| New public content | Rebuild and activate output | Publication policy and cache refresh |
| Server operations | Declared dynamic service dependency | Application operations and configured services |
The Hugo adapter emits the required project inputs and invokes Hugo through its wrapper. Hugo has its own content, layout and asset structure; an arbitrary Blazor DLL is not a Hugo template. Hugo directory structure (ouvre dans une nouvelle fenêtre).
Changes take different paths
Model changes may affect generated types, routes and EF mappings. Their application may need a rebuild, restart or migration even when a simple method edit could hot reload. dotnet watch documents supported changes and restart handling. Official watch reference (ouvre dans une nouvelle fenêtre).
The watcher observes the intended durable workspace. Container-mounted files may require provider-specific watching configuration. Installing a compiled extension, changing a DI graph and applying a hot-reload delta are distinct operations.
Compatibility feedback
A renderer must reject an unsupported component or report its missing service before activation. A failed build preserves the identifiable previous release; a failing preview displays its state instead of pretending that the saved code is running.
See Workspaces, IDEs and Hot Reload for the proposed interaction contract.
Previous: Bundles, Binary Wrappers and Infrastructure · Next: The Self-Describing Lab · Series index · Section index