DotVVM: an ASP.NET framework where the view is HTML and the binding is the program

Views are HTML with a colon, and the view model is a plain C# class

DotVVM lets you build interactive web UIs with just C# and HTML using the MVVM approach, and it simplifies building line of business web apps. The claim is that the two halves stay conventional: the ViewModels are plain C# objects with properties and methods, and the Views use HTML syntax with controls and data bindings.

What makes it a framework rather than a convention is the binding syntax, which is not valid HTML and therefore needs a server side parser. A DotVVM view looks like this:

<div class="form-control">
    <dot:TextBox Text="{value: Name}" />
</div>
<div class="form-control">
    <dot:TextBox Text="{value: Email}" />
</div>
<div class="button-bar">
    <dot:Button Text="Submit" Click="{command: Submit()}" />
</div>

And the view model it binds to is an ordinary class, with data annotation attributes doing the validation work:

public class ContactFormViewModel
{
    [Required]
    public string Name { get; set; }

    [EmailAddress]
    public string Email { get; set; }

    public void Submit()
    {
        // ...
    }
}

The dot prefix marks a control, {value: Name} binds a property and {command: Submit()} binds a method. There is no client side framework in this picture and no serialisation layer between the view and the view model, which is the point: the same class you write for the form is the class you can instantiate in a unit test.

The binding syntax is the whole programming model

It is worth being precise about what the two binding forms do, because they are the entire contract between the view and the view model.

A value binding reads a property and pushes changes back. A command binding calls a method when the user acts. That is the complete surface area for interactivity, and it is deliberately small. There is no expression language to learn beyond those two forms, no client side state to reconcile, and no observable machinery.

The consequence is that a DotVVM application is a server application with a rendering step. The framework does server-side rendering, and it also has SPA support for the cases where a single page application is what you actually want. The README also lists binding to REST APIs and patching a view model using static commands, which is the escape hatch for the situation where the data does not come from the view model at all.

Master pages and user controls cover the layout and composition side, and routing is built in. The .NET integration is deeper than just the language: advanced validation rules integrated with .NET data annotation attributes is what the [Required] and [EmailAddress] attributes above are doing, and support for .NET cultures, number and date formats and RESX localisation means the same code handles culture specific formatting that an ad hoc implementation usually gets wrong.

Taken together, this is a framework aimed at business applications rather than at content sites: grids, uploads, validation and navigation are first class, and they are the pieces a line of business application spends its time on.

The control library is where most of the value sits

The built-in control set is long enough to describe the intended application. The data controls are GridView, the Repeater and FileUpload. The input controls are TextBox, ComboBox, CheckBox and RadioButton. The command controls are Button, LinkButton and RouteLink. The validation controls are Validator and ValidationSummary, and the list is explicitly open ended with an ellipsis at the end.

GridView is the one to look at first, because in a business application the grid is where most of the time goes, and having one that is bound to a collection with editing, sorting and paging handled for you is a large amount of code avoided. FileUpload is the other, since upload handling in a hand written form means chunking, validation and progress that most teams do not want to write.

The rest of the feature list reinforces the same shape. Routing and master pages for navigation, user controls for composition, dependency injection so the view models stay testable, and server-side rendering so the first request does not need a client framework to produce content. The README also notes that DotVVM can run side by side with other ASP.NET frameworks, Web Forms, MVC and Razor Pages, which matters for anyone migrating an existing application rather than starting a new one.

The tooling is the part a new user touches first, and it is genuinely good: IntelliSense and tooling for Visual Studio 2019, for Visual Studio 2022 and for Visual Studio Code.

Three ways in: a template, a command line, or an existing app

The getting started section is unusually practical. The easiest way to start is to download DotVVM for Visual Studio and use File and New and Project, and there are free extensions for Visual Studio 2019 and Visual Studio 2022, plus a free extension for Visual Studio Code.

For people who prefer the command line there is a dotnet new template, which is the route to take in a container or a CI pipeline. And for the case that matters most in a large organisation, the framework can be installed into existing ASP.NET projects and used side by side with other ASP.NET frameworks, so a single application can serve a legacy Web Forms area and a new DotVVM area at once.

There is also the DotVVM Academy, a set of tutorials covering the basic principles, and a Discourse forum at forum.dotvvm.com for questions. Packages are published to NuGet, and the repository badge shows both a stable and a preview feed, which matches the release pattern.

Two things are worth noting about the tooling and the framework. The Visual Studio and VS Code extensions are free but not open source, which the README states plainly, and the framework itself is open source and, in the README's words, will always be free to use. The split matters for anyone writing a procurement note.

Two hosting models with very different minimums

The current status section gives a table that answers most of the first questions, and the two columns are far apart. For ASP.NET Core, the current stable version is DotVVM.AspNetCore 5.0.*, the minimum runtime is .NET 8.0 and the minimum ASP.NET version is ASP.NET Core 8.0. For OWIN, the current stable version is DotVVM.Owin 5.0.*, the minimum runtime is .NET 4.7.2 and the minimum OWIN version is 4.2.2.

So the OWIN line is what keeps DotVVM viable inside a .NET Framework application that cannot be moved, while the ASP.NET Core line is what a new project on modern .NET would use. Both are on the 5.0 major version, so the API is shared and the difference is the hosting stack underneath.

The README also states that DotVVM is used in production by hundreds of developers and companies, and that the first stable release was in June 2016. That is a decade of production history, which matters for a framework where your application code depends on a specific binding and control behaviour.

The release record backs the versioning story. Recent tags are v4.3.16 on 2026-06-27, v5.0.0-preview11 on 2026-08-08 and v5.0.0 on 2026-08-21, so the 5.0 major landed after a run of previews, and the roadmap for the next releases is in roadmap.md at the root of the repository.

Where DotVVM is the wrong choice

The first wrong fit is a team that has standardised on a JavaScript front end. DotVVM's value is that the browser does not run your application logic, so if your organisation has already decided that the client owns the state and the server serves JSON, a server-side view framework is the wrong shape rather than a missing feature.

The second is a project that needs a large catalogue of third party components. The built-in controls cover the business application basics well, but a grid with a specific feature set or a rich editor usually means a commercial component, and the README is explicit about the model. Bootstrap for DotVVM brings more than fifty Bootstrap 3 and 4 controls, and there is a DotVVM Business Pack alongside it. The framework is free and always will be; the extra controls and some tools are paid.

The third is an environment that cannot host a long lived server application. DotVVM needs an ASP.NET Core host or an OWIN host, a runtime on .NET 8.0 or .NET Framework 4.7.2 depending on the line, and somewhere to run it. A static hosting target is out of the question, and a serverless function model is a poor fit even though the SPA support exists, because the point of the framework is the server side round trip.

The fourth is a team that wants the whole stack to be open source. The framework is Apache 2.0 licensed and the repository carries the LICENSE file, but the Visual Studio and VS Code extensions are free and closed, and the commercial components are paid. The open source part is the framework, and it is a good part; the tooling around it is a mix.

The fifth is a greenfield team without a .NET background, where the friction of the framework is not worth it. The value of DotVVM is that it removes work you would otherwise do in JavaScript, and that trade only pays if the team is already comfortable in the .NET world where the view models, the validation attributes and the dependency injection live.

Editorial conclusion

DotVVM fits a .NET team that wants server-side interactive web applications with view models you can unit test, and that would rather not write JavaScript for forms, grids and validation by hand. It does not fit a team that has moved to a JavaScript front end, and it does not fit a project that needs a public component catalogue without paying for one. Before starting, check the minimum runtime for your hosting model, because the ASP.NET Core and OWIN lines sit on very different .NET versions.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. riganti/dotvvm on GitHub