DotVVM 2.4.0-preview01 with support for .NET Core 3.0

Few days ago, we have published the first public preview of DotVVM 2.4.0. In contrast to previous releases which contained mostly fixes or small improvements, this time we have introduced several larger features into the version 2.4, and because they need extensive testing on real-world applications, they will be treated as experimental for some time. After version 2.4, we plan to focus on DotVVM 3.0 which should have these large features production-ready.

We’ve also reached an important milestone of 4096 commits in the repository.

Support for ASP.NET Core 3.0

We have handled the breaking change in Microsoft.AspNetCore.Authorization between 2.2 and 3.0, and included ASP.NET Core 3.0 in all tests to be sure DotVVM is fully supported on ASP.NET Core 3.0.

DotVVM is now fully suported (and tested) on:

• OWIN and .NET Framework 4.5.1
• ASP.NET Core 2.1 (LTS - Long-term Supported release)
• ASP.NET Core 3.0 (latest release)

Our plan is to always support the LTS releases and the last stable release of ASP.NET Core.

If you are still running on ASP.NET Core 2.0, upgrade soon as we plan to change the minimum supported version of ASP.NET Core to 2.1 in the future.

Mobile development for DotVVM – Lazy CSRF protection

Many developers have started using Progressive Web Apps technology to build their mobile applications, and we’d like to make sure DotVVM is ready for this scenario. The process involves multiple larger tasks, and one of them is compatibility with Service Workers that are able cache DotVVM pages on the device. In order to make this cache mechanism working, we need to do a change in CSRF protection that is built-in in DotVVM.

By default, every DotVVM application creates a session cookie with a unique ID (it’s just a random value) and includes a CSRF token in every page. This token is basically a hash which incorporates current page URL, the ID of the currently-logged user, and the ID from the cookie. The token is then checked on every postback.

However, if you need to cache the HTML rendered by DotVVM, the CSRF token should not be “baked” in it. Instead, it should be requested before the user makes the first postback.

That’s why we have implemented Lazy-loading of the CSRF tokens. If you turn this feature on, the token will not be present in the page HTML, and when the user makes the first postback, DotVVM will make two HTTP requests – the first one will ask for the CSRF token, and the second one will be the postback itself.

To turn this feature on, you need to enable this experimental feature.

config.ExperimentalFeatures.LazyCsrfToken.EnableForAllRoutes();

Note that you can also turn this feature only for particular routes, or exclude particular routes from it.

config.ExperimentalFeatures.LazyCsrfToken.EnableForRoutes("MyRoute");
// or 
config.ExperimentalFeatures.LazyCsrfToken.EnableForAllRoutesExcept("ExcludedRoute");

ValidationSummary performance improvements

We have redesigned a bit how the client-side validation works. The errors are not stored in a knockout observable anymore, changes in validation errors can be observed using the validationErrorsChanged event. If you have been using validationErrors directly, you'll have to adjust it's usage as it's not ko.observable anymore.

Special chars allowed in HTML attributes

The DotHTML parser was more strict in resolution of HTML attribute names – the specs allows to use square [] and round () brackets. These characters are used by various frameworks or JS libraries, and also in AMP which may be one of the future directions for DotVVM.

Recently, we were discussing the possibility to auto-generate AMP version for a DotVVM page. There would be of course many restrictions becasue of AMP (most DotVVM controls wouldn’t work, only resource bindings and server rendering could be used), but we can imagine it for simple publishing sites (blogs etc.).

TextBox UpdateTextAfterKeydown changed to UpdateTextOnInput

The UpdateTextAfterKeydown property was marked as obsolete. It was using the keypress event which didn't work on mobile devices and in other scenarios. The framework now uses oninput event for the same purpose.

There is also a new event called TextInput which triggers in this case. Be careful not to trigger postbacks which transmit huge viewmodels - we encourage you to use static command with this event.

Design-Time Error Checking in CheckBox, RadioButton and ComboBox

We have added error checking for various controls that contain combination of properties whose data-binding types must match. The controls didn't work properly and sometimes their behavior was unpredictable when the types were different.

<dot:CheckBox CheckedItems="{value: _parent.SelectedIds}" CheckedValue="{value: Id}" />

The framework now checks that CheckedValue binding type is T and SelectedIds type is IEnumerable<T> (or IEnumerable<Nullable<T>>). Similar rules apply to RadioButton and ComboBox.

We recommend to use Diagnostics Status Page and check that all pages in your application use these controls correctly.

There are also many tiny fixes and improvements, especially in the debugging and diagnostics areas. For example, DotVVM resources render helpful comments with resource names and other information. There are also some improvements and fixes to the DotVVM error page. See Release notes for full details.

What’s Next

There is one large feature that didn’t get merged into Preview 1 – Server-side viewmodel caching which I’ve blogged about recently.

It is a very important change for DotVVM and it is believed to bringe huge performance benefits, but there is still a lot of work to do – we are missing diagnostics tools that would advise on which pages the feature should be turned on. But we plan to have this feature as experimental in DotVVM 2.4.