DotVVM 2.2
TL;DR; There are some new minor features. The most important point is Validation - EnforceClientFormat, which may break some existing code if it is using DateTime or nullable numberic type in view model.
New features
Binding Cache
We have added caching interface IDotvvmCacheAdapter that provides access to built-in caching mechanism on Asp.Net Core or OWIN that reflect memory usage on your server.
ValueBindingExpression.CreateThisBinding is now cached, so it's invocation should be quite cheap.
When you want to create binding at runtime you can now use a helper method DotvvmBindingCacheHelper.CreateCachedBinding that makes sure that the binding is not recreated every time. Creation of bindings is usually time-consuming, so it should not be done on every request. (more info in PRs #672 and #664)
By the way, we have also (hopefully) improved the error messages when something fails with binding. When an error page is displayed for a binding-related exception, there is a new tab Binding that shows some information about the binding (data context, type, ...). Let us know what you think about that and what could be improved.
Validation
ValidationErrorFactory.CreateValidationResult<T>(ValidationContext validationContext, ...)
Overload that does not require explicitDotvvmConfiguration
Session cookies are SameSite
This was sometimes the case before. It means that postbacks won't work in third-party iframes (so your application should be safe from clickjacking).
Fixes
Validation - EnforceClientFormat
This part is a fix and unfortunately a breaking change at the same time. In older versions, DotVVM did not validate that DateTime and numeric fields were valid on the client-side and sent null to the server in that case. It could be enabled by EnforceClientFormatAttribute, but nobody really did. It is now by default enabled on nullable numeric types, DateTime, and DateTime?, so it enables validation in cases where it was disabled previously. While this has a potential to "fix" existing code as not validating the input is likely a bug, it may also break some code that relied on that behavior. Please make sure that all your views using nullable DateTime and numerics work as expected. (more info in PR #666)
For example, suppose you had a dot:TextBox bound to a property of type int?. The problem is that when you paste value like "asd", it will write a null value into the property because "asd" is not a valid numeric value. The solution for this problem was applying EnforceClientFormatAttribute to the property in your view model. Now, you don't have to do that anymore. If you use that attribute somewhere, you can safely remove it.
Repeater control initialization
We have change a bit how the Repeater initialization works. Controls with templates have to initialize the control tree before it is used by command invocation and HTML rendering and when this initialization is dependent on data from view model, it has to be done twice on postbacks - once before command invocation and then before rendering since the command may have changed the data. In older version Repeater have not done that in all cases, because it's quite time-consuming. Unfortunately, in some cases, it broke some code, so we are now re-initializing it two times, but only in case the data is actually changed. (more info in #653)
Unique id generation for nested trees
If you were creating controls at runtime, you may know that before adding more child controls into the newly create control has to be added to the control tree. The reason was, that the mechanism that generates unique ID (for control command and Postback.Update) did not work correctly when entire subtree was added at once. From this version, this should work correctly, so you can initialize entire subtrees at once. (more info in #668)
dot:RouteLink in Events.Click container
It should now get precedence over the Events.Click handler. (more info in #630)
DotvvmAuthenticationHelper.ApplyRedirectResponse
Fixed in DotVVM 2.2.0.2
When you installed Microsoft.Extensions.DependencyInjection 2.1.0 or higher in your application and used DotvvmAuthenticationHelper.ApplyRedirectResponse, this method was throwing an exception with a message that ServiceProvider had been disposed.
netstandard assembly loading on .NET Framework 4.7.1+
Fixed in DotVVM 2.2.0.2
DotVVM View compilation on .NET471+ was not able to load netstandard assembly.