Client-Side ASP.NET MVC Runtime for WebAssembly.
Run Controllers, Razor Views, EF Core, Identity, and SignalR
entirely in the browser — no server required.
MVC is the most widely adopted .NET web programming model — yet it requires a server. Developers with large MVC codebases have no path to deploy as static SPAs, to edge runtimes, or to offline-capable environments without a full rewrite.
The .NET runtime boots inside a Web Worker. The main thread is a thin display surface that receives pre-rendered HTML frames and applies them at 60fps.
A complete ASP.NET MVC runtime — Controllers, Views, Database, Auth, Real-time — compiled to WebAssembly and deployed as static files.
Controller base class with ViewData, ViewBag, TempData, ModelState. Attribute routing, Areas, ApiController, and convention-based routing.
Runtime template engine processes @Model, @ViewData, @if, @foreach, @RenderBody, @section, Html.PartialAsync, and asp-* tag helpers.
Full Entity Framework Core with SQLite compiled to WASM. LINQ, migrations, relationships. Database persisted to OPFS.
PBKDF2-SHA256 hashing, HMAC-signed session tokens, fingerprint binding, account lockout, cross-tab auth sync.
Hub discovery via reflection, Clients.All/Caller/Others/Group proxies, connection management — all running in-process.
Same code runs as a browser SPA or a Node.js/Edge API. Deploy to Cloudflare Workers, Deno, or Lambda@Edge.
[Authorize], [AllowAnonymous], role-based access control, claims-based policies — enforced at the MvcEngine level before action invocation.
WebAuthn/FIDO2 passkey registration, RFC 6238 TOTP authenticator with real QR codes, recovery codes — following aspnetcore patterns.
Fluent AddWasmIdentity() builder: external OAuth providers, custom token providers, password policy, admin seeding — mirrors ASP.NET Core IdentityBuilder.
Full Visual Studio debugging with pre-configured launchSettings.json — press F5 and debug your WASM MVC app with breakpoints, watch, and hot reload.
All 70 source files enforce strict ASP.NET Core API fidelity. AI-assisted code generation must consult SDK_DEVELOPMENT_STANDARDS.md — zero deviation from the official surface.
[StreamingResponse] for NDJSON/SSE IAsyncEnumerable rendering. SignalR stream protocol with char-by-char chat demo. Opt-in per action — default buffered for safety.
Install the SDK or CLI, scaffold a project, and deploy as static files.
# Install globally
dotnet tool install --global Cepha.CLI
# Create a new project
cepha new MyApp
cepha new MyApp --identity # with auth<!-- MyApp.csproj -->
<Project Sdk="NetWasmMvc.SDK/1.0.20">
<PropertyGroup>
<TargetFramework>net10.0</TargetFramework>
</PropertyGroup>
</Project>// Standard MVC — works unchanged
public class HomeController : Controller
{
public IActionResult Index()
{
ViewData["Title"] = "Welcome";
return View();
}
}
// Extensible Identity Builder
services.AddWasmIdentity(options =>
{
options.Password.RequiredLength = 10;
options.TwoFactor.EnableAuthenticator = true;
options.SeedAdmin("admin@cepha.local", "Admin@Cepha!2025");
})
.AddPassKeys()
.AddExternalProvider("Google", p =>
{
p.ClientId = "your-client-id";
p.ClientSecret = "your-secret";
})
.AddDefaultTokenProviders();# Build
dotnet publish -c Release
# Output: static files (HTML, JS, WASM)
# Deploy to any CDN, GitHub Pages,
# Cloudflare Pages, Azure Static Web Apps
cepha publish cf # one-command deployThe core runtime is complete. Here's where we're headed.
This runtime is being proposed as an experimental hosting model for .NET 11. The proposal requests targeted infrastructure — an SDK target, a lightweight MvcEngine, and a Razor template contract — not a new framework.
Feature proposal for dotnet/aspnetcore Discussions. Problem statement, proposed solution, what we're asking from the .NET team.
Read proposal →Thread model, rendering pipeline, bootstrap sequence, JS interop, and design decisions behind the runtime.
Read architecture →PBKDF2 hashing, HMAC session tokens, IdentityAtom binary protocol, fingerprint binding, threat mitigations.
Read security model →CI pipeline with 46+ automated checks: identity standards, cryptographic compliance, PCI-DSS v4.0 audit trail.
View audit workflow →
The .NET WebAssembly toolchain has critical gaps that prevent MVC apps from publishing correctly
via Visual Studio. Cepha (Cepha.CLI + NetWasmMvc.SDK) was built to bridge these gaps.
The following issues remain open in the .NET runtime and directly affect this proposal.
When publishing a browser-wasm project from Visual Studio's Publish dialog,
the destination folder is completely empty — no _framework/,
no wwwroot/, no index.html. The same project publishes correctly
via dotnet publish -c Release from the command line.
Impact: Developers cannot use Visual Studio's standard Publish workflow for WebAssembly MVC apps. This is a fundamental tooling gap that prevents adoption in enterprise environments where VS-integrated deployment is expected.
The core proposal filed in dotnet/runtime. .NET currently provides no SDK target,
no MvcEngine, and no Razor template contract for running MVC in WebAssembly.
The entire MVC pipeline assumes a server host — there is no
Microsoft.NET.Sdk.WebAssembly.Mvc.
Status: Open · Milestone: Future · Labels: area-Meta, os-browser
The companion discussion in dotnet/runtime seeking community feedback on whether
client-side MVC for WebAssembly should be officially supported. Covers bundle size concerns,
NativeAOT timeline, edge deployment interest, and the relationship with Blazor.
Key question: Should this start as an experimental SDK — similar to how Blazor began — to let the community validate the model before full investment?
While these runtime issues remain open, Cepha provides a complete solution today:
a custom SDK target (NetWasmMvc.SDK), a lightweight MvcEngine, a Razor template engine,
CLI tooling with cepha dev / cepha publish, and correct
dotnet publish output for browser-wasm.
Cepha solves today what the .NET team has acknowledged as a gap for .NET 11+.
Install Cepha.CLI and start building MVC WebAssembly apps now — no server required.