DotVVM 4.3.2 bugfix release

• JS Translations
  • Fix knockout observable handling in LastOrDefault, FirstOrDefault and other LINQ translations (#1871)
    • This bug was a regression in 4.3.0
• DotvvmCapabilityProperty
  • Fix assignment of default value in overridden DotvvmProperties (#1863)

DotVVM 4.3.1 bugfix release

• Validation
  • ValidationContext (used in IValidatableObject) has an initialized IServiceProvider (#1869)
• Analyzers
  • DotVVM04 warning is supressed in Linq.Expressions, such as in ValueOrBinding.Select (#1859)
  • DotVVM02 warning works correctly with overriden properties (#1858)
• DotvvmCapabilityProperty
  • NullReferenceException is not thrown when a property of type ValueOrBinding<int>? is set to null in the control (#1864)
  • Fix assignment of default value in overridden DotvvmProperties (#1863)
  • Fix reading of inherited DotvvmProperty (#1862)

DotVVM 4.3

DotVVM 4.3 includes two new built-in controls — ModalDialog and AddTemplateDecorator; a major upgrade of the routing system — route localization; better system for warnings; a dozen of new JS translations; and a number of bug fixes and performance improvements, such as the postback request compression.

Potential breaking changes

First, we present to you the bad news. Although we try to limit the number of breakages in minor versions, it if often impossible to fix serious glitches without changing the behavior of some components:

• Client-side dotvvm.state object is now frozen. Its modification will throw an exception when in JS strict mode (#1782). Previously, the modification was silently ignored.
• Newtonsoft.Json was updated to 13.0.3
• Removed a redundant Microsoft.CodeAnalysis.CSharp dependency from DotVVM.AspNetCore. You might need to explicitly add it back if your application needs the package.
• If two @property directives define a property with the same name, an error is issued.
• Controls registered using AutoDiscoverControls now use relative file paths instead of absolute paths in the Src property (#1817)

If you encounter any other regressions, please let us know, as they would most likely be accidental.

dot:ModalDialog - wrapper for the HTML <dialog> element (#1776)

DotVVM now includes a dot:ModalDialog control which wraps the new native HTML <dialog> element. It does not replace the dialogs in Bootstrap or BusinessPack, as it isn't styled.

<dot:ModalDialog Open={value: ShowDialog} CloseOnBackdropClick>
    content
</dot:ModalDialog>

dot:ModalDialog only supports the modal version of <dialog>, as the non-modal version is accessible through basic HTML with a bidning in the open attribute - <dialog open={value: ShowInlineDialog}>

New dot:AddTemplateDecorator control (#1760)

dot:AddTemplateDecorator is a new decorator which can prepend or append content to the decorated element. For example, you might use it to add an additional row to each entry in a grid view. In the following snippet, we use this to add a separate row for a description field, which is otherwise too long to fit into a table column.

<dot:GridView DataSource={value: MyTable}>
    <RowDecorators>
        <dot:AddTemplateDecorator>
            <AfterTemplate>
                <tr> <td colspan="8">{{value: Description}}</td> </tr>
            </AfterTemplate>
        </dot:AddTemplateDecorator>
    </RowDecorators>
    <Columns>
        ...
    </Columns>
</dot:GridView>

Localizable routes (#1824, #1840)

DotVVM now has a mechanism for localizing the route URLs. First, you need to apply a middleware which sets the correct CurrentCulture based on url prefix or the Accept-Language header.

Based on CurrentCulture, DotVVM will decide to which language should the route URL match. By default, DotVVM does not consider alternative languages. You can reconfigure it to accept alternative URL languages or to redirect to the "correct" language variant.

In the following example, we register a localized route and configure DotVVM to redirect if the route language does not match the selected language. If we take requested culture from Accept-Language or a cookie, we probably want to redirect users to the URL language of their preference:

config.RouteTable.Add("MyLocalizableRoute", "localizable-route", "Views/LocalizableRoute.dothtml",
    localizedUrls: [
            new("cs", "lokalizovana-routa"),
            new("de", "lokalisierte-route"),
    ]);
// redirect to a matching language based on CultureInfo.CurrentCulture
config.RouteTable.AddPartialMatchHandler(new CanonicalRedirectPartialMatchRouteHandler());

Related to route localization, we have added the dot:AlternateCultureLinks control which automatically generates <link rel=alternate> elements pointing to the alternative language variants.

Warnings

The Compilation Status Page normally available at _dotvvm/diagnostics/compilation now lists the warnings and errors of all compiled views. We strongly recommend you to examine the compilation page after upgrading, as it might uncover many mistakes in the application. Thanks to these warnings, we have fixed tens of small UI glitches on one of our systems, which were caused by wrong usage of some DotVVM properties. (related forum post, #1762)

The Control usage validation API now allows controls to emit custom warnings (#1751). For instance, you might want the user about a potential issue, such as specifying a redundant property:

[ControlUsageValidator]
public static IEnumerable<ControlUsageError> ValidateUsage(ResolvedControl control)
{
    if (control.Properties.ContainsKey(LabelProperty) && control.Properties.ContainsKey(SomeTemplateProperty))
    {
        var propertyNode = control.GetValue(LabelProperty).DothtmlNode;
        yield return new ControlUsageError("Label is ignored when SomeTemplate is also specified.", DiagnosticSeverity.Warning, propertyNode);
    }
}

POST compression (#1766)

DotVVM 4.3 will use gzip to compress the command and staticCommand request bodies. As the requests are in JSON, the performance gain is quite significant if you aren't on gigabit Ethernet.

However, accepting compressed requests carries a risk of exposing the web server to "compression bomb" DOS attacks. To limit the potential impact, DotVVM now limits the maximum (uncompressed) postback size to 128 MiB, and the limit may be configured in config.Runtime.MaxPostbackSizeBytes (it doesn't affect file upload). Postback compression may also be disabled using the config.Runtime.CompressPostbacks option.

Note that request compression is only enabled in Production environment, because browsers are currently unable to display the uncompressed JSON in devtools.

Other improvements

• Markup file recompilation can be enabled in Production mode using the DotvvmConfiguration.Runtime.ReloadMarkupFiles option.
• Changed operation name in DotVVM.Tracing.ApplicationInsights to the current route URL template (#1807, thanks to @mirecad)
• JS translations now avoid throwing exception even when the .NET equivalent does throw.
• New JS translations
  • IEnumerable.Last, IEnumerable.First
  • Dictionary.GetValueOrDefault
  • TimeOnly.Hour, Minute, Second, Millisecond, FromDateTime
  • DateOnly.Year, Month, Date, FromDateTime
  • DateTime.Now, UtcNow, Today
• GridViewColumn.Visible now accepts a resource binding (#1826)
• Added methods for compiling command and resource bindings from string to BindingCompilationService.Cache (#1839)
• Client-side DotVVM logging may be configured using the dotvvm.logging.setLogger function. Note that the exact wording of log messages is not stable and may even differ in Development and Production environments.
• Performance improvements, mainly HTML encoding in HtmlWriter thanks for the vectorized IndexOfAny implementation (#1851)
• InlineScriptResource can now produce <script type=module when module parameter is specified.
• Prevent double postbacks after redirect in Deny or Queue PostBack.Concurrency mode by pretending that the redirect takes 5 seconds. Before those 5s pass, the page most likely unloads and the user does not get the chance to submit the duplicate postback (#1853)
• Improved error messages (#1731, #1748, #1763, #1772, #1804, #1806)

Bugs/glitches fixed

• The client-side ViewModel is now restored on back/forward navigation (fixed in Chrome) and not restored on page reload (fixed in Firefox) (#1848)
• DotVVM.AspNetCore does not depend on Microsoft.CodeAnalysis.CSharp (#1743)
• Lambda argument type inference works for custom delegates (#1752)
• The "Force recompile all" button in the Compilation Status Page now actually forces rebuild of all pages (#1759)
• Fixed overload resolution of generic methods with default arguments (#1761)
• Fixed support for client-side property names which are not valid JS identifiers (#1790)
• Client-side validation is now correctly performed on typed objects inside a untyped object (#1803)
• (#1816)
• Controls registered using AutoDiscoverControls now use relative file paths (#1817)
• Remove defer attribute from <script type=module element as it is redundant and invalid HTML
• Limit the number of queued Tasks when doing pre-compilation to avoid stalling the ThreadPool (#1843)
• Fixed the CopyProperty method to work with inherited properties containing bindings (#1850)

Thanks to @tomasherceg, @Mylan719, @mirecad, @exyi for contributing to this release

DotVVM 4.2

Potential breaking changes

DotVVM 4.2 should generally be source compatible with the previous 4.1 version. We did not preserve binary compatibility, so please make sure all other DotVVM packages are at 4.2 version (especially if you see a MissingMethodException or similar error). Please let us know if we forgot to update some of our packages. We also had to change the behavior in ways which could in theory break something

• The type hashes (the client-side type metadata id) might be different. You might need to adjust if you have it hardcoded somewhere. (see #1614, should only affect generic types)
• HtmlGenericControl and RadioButton now attempts to render both the server-side value and client-side binding regardless of RenderSettings.Mode. If you relied on the value not being pre-rendered on the server, please explicitly use _page.EvaluatingOnServer ? null : OriginalExpression. To render value server-side only, switch to a resource binding.
• Using a non-DotvvmProperty defined on a markup control is now a compile-time error (in value bindings). It used to only fail client-side
• DotVVM does not reload dothtml files when run in Production environment (when DotvvmConfiguration.Debug=false).
• JsComponent is always initialized asynchronously (see #1684)
• View Modules are always initialized after dotvvm is initialized
• Operator precedence of && and || now behaves the same as in C#
• Unopened closing tag used to close all currently open elements -- for example in <a></b> the b tag closed the a tag. This glitch caused all sorts of problems, so we changed it to not close any elements.
• RadioButton.Checked is deprecated, please use CheckedValue and CheckedItem properties (the property never worked, but now it might fail compile-time if used incorrectly)

staticCommand validation

Server-side validation now works in staticCommand methods. The validation has to be enabled using [AllowStaticCommand(StaticCommandValidation.Manual)] or [AllowStaticCommand(StaticCommandValidation.Automatic)] attribute. In the Automatic case, all arguments will be recursively validated using DataAnnotations attributes and IValidatableObject.Validate will be called. In both cases, additional validation errors can be returned using the StaticCommandModelState class:

[AllowStaticCommand(StaticCommandValidation.Manual)]
public string MyMethod(MyModel model)
{
    var modelState = new StaticCommandModelState();
    modelState.AddArgumentError(() => model.Property, "Property is invalid");
    modelState.FailOnInvalidModelState();
}

Enabling the validation will make the staticCommand invocation clear all validation errors currently being shown client-side. Note that client-side validation isn't currently implemented, so all invocation will round-trip to the server.

See related forum post for more examples.

Custom primitive types

In order to better support typed IDs, DotVVM now has support for custom primitive types. These types are always represented as a string client-side, which makes them allowed in places only for primitive types - notably SelectedValue property on selector components, but also in route parameters, and html attributes.

The custom primitive type must have ToString() and static TryParse(string, out T) methods. It must also implement the IDotvvmPrimitiveType interface. It's only a marker interface, since ToString method present on all types, and TryParse method is static and we can't use interface static methods due to support for the old framework. The type can be a class, a struct or a record.

A simple typed ID type could look like the following:

public struct OrderId: IDotvvmPrimitiveType
{
    public int Value { get; }
    public OrderId(int value)
    {
        this.Value = value;
    }
    public override string ToString() => Value.ToString();
    public static bool TryParse(string value, out OrderId result)
    {
         if (int.TryParse(value, out var resultValue))
         {
             result = new OrderId(resultValue);
             return true;
         }
         result = default;
         return false;
    }
}

WebForms adapters

We have made a new package which helps in the process of migrating Web Forms apps to the new .NET using DotVVM - DotVVM.Adapters.WebForms. It currently contains HybridRouteLink control and RedirectToRouteHybrid extension method.

• The <webforms:HybridRouteLink> control has the same functionality as the RouteLink control, but it falls back to Web Forms routes when a requested DotVVM route doesn't exist (which means that the page hasn't been migrated yet).
• The RedirectToRouteHybrid extension method of the IDotvvmRequestContext also falls back to the Web Forms route in case the DotVVM route doesn't exist.

The package also works on .NET Core, where these fallbacks are disabled (because of the absence of System.Web). This allows to keep using the API even after the migration is finished.

state, patchState, setState, updateState in JS View Modules

We have added the state property and the following methods to the global dotvvm object, viewmodel knockout observables and JS module context (DotvvmModuleContext)

• state - returns the current value of the view model
• setState(newValue) - replaces the current value
• patchState(newValues) - replaces only the specified properties, for example patchState({ UserName: "new-user" })
• updateState(currentValue => computeNewValue(currentValue)) - applies the specified function onto the current view model

See simplified view model API in JS Modules on forum.dotvvm.com for more details and some context.

Knockout deferred updates (experimental feature)

DotVVM uses knockout.js to immediately synchronize the view model into the HTML DOM. Knockout essentially does this by subscribing to an update event on each view model variable which is used in the binding. When any value inside the view model is changed, all bindings using the value immediately get a notification and update the bound DOM element.

This normally works well, but if the binding uses very many different variables it can get equally many notification if large part of the view model gets changed. For example, you can have a binding which enumerates an array by counting number of certain elements in an array ({value: MyArray.Count(a => a.IsSpecial)}). Each array element is a separate viewmodel value, so the binding with get up to MyArray.Length update notifications, each time evaluating the binding and updating the DOM element. This mean we have got O(n^2) worst case complexity for updating the view model, which can be really slow (in some cases).

Knockout has got an ko.options.deferUpdates = true option, which makes the updates asynchronous and deduplicates the notifications. Updating all array elements will then lead to just one DOM update (with a slight delay). It was always possible to enable this option, in 4.2 we made it easier to enable and fixed a few bugs in DotVVM which occurred when delayed updates were enabled. The feature is still experimental, since we didn't thoroughly test it with all our components. You can enable/disable it for certain pages, if you encounter issues.

config.ExperimentalFeatures.KnockoutDeferUpdates.Enable().ExcludeRoute("SomePageThatOtherwiseBreaks");

Metrics

We instrumented DotVVM with System.Diagnostics.Metrics. All implemented metrics are listed in the DotvvmMetrics.cs file. We'd like to point out some of the important or interesting metrics:

• dotvvm_viewmodel_size_bytes histogram - Size of the returned viewmodel JSON in bytes.
  • Labels route=RouteName and request_type=Navigate/SpaNavigate/Command/StaticCommand
• dotvvm_request_duration_seconds - Time it took to stringify the resulting JSON view model.
  • Labels route, request_type and dothtml_file
  • You can use ASP.NET Core statistics about request duration, this metric makes it possible to split the measurement by DotVVM route name.
• dotvvm_viewmodel_serialization_seconds histogram - Time it took to serialize view model to JSON objects.
  • Labels route and request_type
• dotvvm_control_lifecycle_seconds histogram - Time it took to process a request on the specific route
  • Labels route and lifecycle_type=PreInit/Init/Load/PreRender/PreRenderComplete
• dotvvm_command_invocation_seconds - Time it took to invoke a specific command method. Compared to request_duration_seconds this only includes the time spent in the command method, and is labeled by the executed binding (command)
  • Labels command and result=Ok/Exception/UnhandledException
• dotvvm_staticcommand_invocation_seconds - Similar to command_invocation_seconds, but for staticCommand invocations
  • Labels command and result=Ok/Exception/UnhandledException
• dotvvm_viewmodel_validation_errors_total histogram - Number view model validation errors returned to the client.
  • Labels route and request_type
• dotvvm_uploaded_file_bytes - Total size of user-uploaded files
• dotvvm_returned_file_bytes - Total size of returned files. Measured when the file is returned, not when downloaded by the client

If you are using Server-side viewmodel cache you might be also ...

DotVVM 4.1

Potentially breaking changes

While we try to keep "minor" releases free of major breaking changes, it's sometimes impossible to avoid. In general, you should not have problems updating to 4.1. If you encounter a breakage not on this list, please submit a bug report to this repository, or contact us on gitter.

• In general, we aim to be source-compatible, not binary-compatible. If you are using other DotVVM packages, make sure all are on 4.1 version; otherwise MissingMethodExceptions (or similar) might occur.
• 4.0 had a bug that allowed using private members from binding. This is fixed in 4.1, so you will now get an error when a private member is used in binding expressions.
• 4.0 had a bug which treated { get; init; } properties as if they had normal setter. DotVVM 4.1 will always clone the object before setting an init-only property.
• We made the ReflectionUtils.PrimitiveTypes collection private. Please use the IsPrimitiveType method. In case it doesn't fulfill your requirement, please contact us. We plan to add support for custom primitive types in the next release.

We recommend using the view compilation page at _dotvvm/diagnostics/compilation after updating to check that all views still compile.

Record serialization (#1246 #1525)

DotVVM can (finally) correctly serialize and deserialize value types and records with constructor properties. F# records and single-case unions are also supported.

record UserInfo(string Name,
                string Id,
                string Email);

In general classes, the non-default constructor has to be marked with the constructor [JsonConstructor] attribute. Without it, DotVVM will not automatically deserialize properties into constructor arguments, even when no other constructor is available (to avoid breaking existing code)

class C {
    public string Name { get; }

    [JsonConstructor]
    public C(string name) {
        this.Name = name;
    }
}

HierarchyRepeater (#1206)

DotVVM now has a generic control for displaying hierarchies that support both client-side and server-side rendering. The following code will create a hierarchy of ul / li tags from a collection of Roots. The ItemWrapperTag (li) only contains a template for a specific item, while LevelWrapperTag (ul) also includes all child items.

<dot:HierarchyRepeater DataSource={value: Roots}
                       ItemChildrenBinding={value: Children}
                       LevelWrapperTagName=ul
                       ItemWrapperTagName=li >
     {{value: Name}}
</dot:HierarchyRepeater>

Note that you can set any other attributes or classes on the wrapper tags using the Level or Item prefix, for example LevelClass-highlighted={value: Name == _root.HighlightedName}.

AutoUI (#1293)

DotVVM Dynamic Data is a library that generates forms and grids automatically from your model classes. We have rewritten it using precompiled CompositeControls and server-side styles. This makes it much easier to extend and customize, and also eliminates performance issues the old DynamicData library had.

We renamed this new implementation as DotVVM AutoUI, as it's... an automatic UI generator, not data and not dynamic :)
The old DynamicData library still works as before, although we don't plan to develop it further.

Since there is a lot to cover, please refer to the dedicated page for more information. In short, this how the usage looks like:

<!-- create from with all the fields -->
<auto:Form DataContext="{value: EditedEmployee}" />

<!-- a table with automatic columns (we support inline editing too) -->
<dot:GridView DataSource="{value: Employees}">
    <auto:GridViewColumns />
</dot:GridView>

<!-- basic form component based on data type and attributes. Includes validation -->
<auto:Editor Property="{value: Age}" />

Markup Declared Properties (#1231)

Properties of markup controls can now be defined directly in the control .dothtml file:

@property string Name

<div class="name">
   {{value: _control.Name}}
</div>

For each property, you can specify:

• A default value, for example
  • @property string Width = "100%"
  • @property string[] Classes = [ "something" ]
  • @property Func<int, int> GetNextId = (int i) => i + 1
• Markup options, for example @property string Name, MarkupOptionsAttribute.Required=true

Note that @baseType and @property directives cannot be combined, as it could lead to ambiguities where the property is defined.

CompositeControl precompilation (#1261)

DotVVM 4.0 introduced Composite controls and made Server-Side Styles much more powerful.

DotVVM 4.1 builds on this foundation and introduces Composite control which is only evaluated once - when the page is being compiled.
This is very useful when the component needs to create and compile new bindings (like Auto UI) since that is a bit too slow to do on each request.
It also allows other server-side styles to match the generated content and customize it.

The usage is fairly simple:

[ControlMarkupOptions(Precompile = ControlPrecompilationMode.IfPossible)]
public class MyControl : CompositeControl
{
    public DotvvmControl GetContents(
        ValueOrBinding<string> myProperty,
        string otherProperty
    )
    {
       return ...;
    }
}

This will try to create the control during page compilation, invoke the GetContents method and replace the component with the generated control tree. The component instance won't even be created at runtime.

However, if otherProperty contains a resource binding, it's not possible to call GetContents before the binding is evaluated. This is fine, the control will be evaluated at runtime normally. You might decide that for certain combinations of arguments, the precompilation is not possible and throw a SkipPrecompilationException. Please try not to depend on cases where DotVVM automatically decides precompilation isn't possible, since we might want to add support for them in future versions. If you want to make sure the control never falls back on runtime evaluation, you can use the ControlPrecompilationMode.Always setting.

A special mode is ControlPrecompilationMode.InServerSideStyles which is used by AutoUI. This instructs DotVVM to build the control while server-side styles are running which allows other styles to modify the children. Normal precompiled controls are evaluated after styles are finished, in order to behave similarly to runtime controls which are also unaffected by styles.

JsComponent is stable now

DotVVM 4.0 included experimental support for integrating components written in JavaScript; as of DotVVM 4.1 we consider the React integration stable. To include a React component into a DotVVM view:

• Install the dotvvm-jscomponent-react npm package
• Setup your favorite JS bundler (and optionally a typescript compiler) to produce ES module bundle (let's say it's called scripts/mycomponents.js)
• Register the script for DotVVM: config.Resources.RegisterScriptModuleFile("mycomponents-js", "script/mycomponents.js")

The module should export the components in the $controls field

import { registerReactControl } from 'dotvvm-jscomponent-react';
import * as React from 'react';

function SampleComponent(props) {
   return <span>{props.text}</span>
}

export default (context) => ({
    $controls: {
        SampleComponent: registerReactControl(SampleComponent),
    }
})

Then you can import it in any DotVVM view or markup control using the @js directive and use it with the <js: tag prefix.

@js mycomponents-js

<js:SampleComponent text={value: Text} />

For more information, see the documentation page, our sample project or the sample we use as UI test.

We'd like to thank @lorencjan for thoroughly testing the dotvvm-jscomponent-react package, many improvements have been made based on his suggestions.

We also have working Svelte integration. However, it's not published as a npm package at the moment - if you want to try it out, you can copy the integration function from our repository (yes the link correct, all the code really fits on one screen). If you'd like to try any other JS web framework, it should be quite easy to wire it into the DotVVM API. We'll definitely welcome any pull requests, but feel free to also submit an issue requesting it. If you can "only" help with testing, that's also very valuable.

Other smaller changes

• DotVVM now implements `IHeathCheck on ASP.NET Core. It checks whether all pages can be compiled. #1209
• control.AddCssClass and control.AddCssStyle extension methods now also support ValueOrBinding as input. It will now also work when it's called multiple times with a binding. (#1274, #1354)
• Control property can now be IEnumerable<DotvvmControl> or IEnumerable<IMyControl>, previously it had to be List<DotvvmControl> (#1325, #1355)
• `BindingCompilationService.Cache.Creat...

DotVVM 4.0

DotVVM 4.0 Release notes

Breaking Changes

ordered by severity:

• We dropped support for IE 11. There is no workaround, except for using some better browser
• Validation API has changed, see the Validation section for more details. TL;DR: use context.AddModelError(this, vm => vm.EditViewModel.MyProperty)
• netstandard2.1 or net472 platform is required
• Some HTTP security headers are enabled by default. See HTTP Security Headers section
• [Authorize] attribute is now deprecated, please use the context.Authorize() extension method instead. The Authorize attribute still works and we don't plan to remove it, but it's marked obsolete for a reason (see Authorization)
• Control properties not using the DotvvmProperty.Register or DotvvmPropertyGroup.Register are no longer supported and exception will be thrown.
• DotvvmControl.SetValue method used to write into the value binding if it was possible. However, this behavior was unreliable so it now always replaces the binding with the new value. If you want the old behavior - to set the value to the binding, use the .SetValueToSource method.
• Some typos in the public API were fixed (see #1051)
• Method in server-side styles .SetControlProperty<MyControl>(TheProperty) is replaced by .SetControlProperty(TheProperty, new MyControl()). Also additional using may be required for extension method to be found.
• DotVVM Error page now only displays errors from DotVVM pages, not from subsequent middlewares. If you are using both DotVVM and other technology in your backend, add the ASP.NET Error Page too.
• Client-side Repeater uses a separate <template id=...> element instead of placing the template inside. If it poses a problem, it can be configured by setting RenderAsNamedTemplate=false.
• RouteLink renders the link even in client-side mode.
• Literal renders the binding even in server-side rendering mode. Use a resource binding to force it to render the value server-side without generating the Knockout binding expression.
• DotVVM.Diagnostics.StatusPage is now deprecated, the page is now included in DotVVM.Framework package (at _dotvvm/diagnostics/compilation). Please uninstall the package from your project.

New Authorization API

TL;DR: Use context.Authorize(...) instead of [Authorize(...)]. Place it in the OnInit method of your view model or into the respective command/staticCommand. The IDotvvmRequestContext can be injected from DI into your static command service constructor or directly imported in DotHTML using @service context=IDotvvmRequestContext and put into staticCommand argument.

We deprecated the [Authorize] attribute, because it was not called in some unexpected cases (when the command is called from another command, or when the view model class is placed inside another view model). We could fix those few issues, but there would probably always remain some weird cases, so we decided to deprecate the auto-magical invocation ofr the attribute in favor of calling the Authorize method explicitly. It's much easier to debug why your code does not invoke the method than to debug why DotVVM won't call it. Also, when the .Authorize call is placed right next to the logic it's supposed to guard, there is almost no way it wasn't in fact authorized. Since developers rarely write UI tests checking whether auth works properly, we decided calling a method is much safer option for such a critical task.

HTTP Security Headers

Firstly, this DOES NOT magically protect your application from all kinds of attacks. Most common attacks are related to wrongly configured authentication and insuficient user input validation, and none of these headers can help with that. Please remember that everything in your viewmodel which is not marked by the [Protect] attribute is suddently a user input in a command or static command.

Also, we only set headers which are not likely to cause any problems to your application... which, incidentally, are the headers which are less effective 🙃. Please don't forget to set the Strict-Transport-Security yourself and check your application using Mozilla Observatory.

• X-Frame-Options: DENY is used by default. It should pose no problem, since DotVVM did not work with iframes anyway due to cookie SameSite policy. When CrossSite frames are enabled, the cookie will have SameSite=None

  • Configured in config.Security.FrameOptionsSameOrigin and config.Security.FrameOptionsSameOrigin. Please enable the cross-origin iframes only for routes where you really need it.

• We also check Sec-Fetch-Dest - if it's an iframe, we validate on server that iframes are allowed. This mostly allows us to print a nicer error message, but may also in theory prevent some timing attacks using iframes

• X-XSS-Protection: 1; mode=block blocks some kinds of XSS attacks. Probably not super useful, but also not harmful.

  • Configured by config.Security.XssProtectionHeader

• X-Content-Type-Options: nosniff disables inference of content-type based on content, this could prevent some XSS attacks. Probably also not super useful, but very unlikely to cause any problems.

  • Configured by config.Security.ContentTypeOptionsHeader

• When on https, we set the session cookie with __Host- prefix. This prevents it being used by subdomains. Can help only in obscure cases - for example when a system on the subdomain is compromised, the attacked can not pivot to the parent domain so easily.

We also check the Sec-Fetch-* headers - that tells us what the browsers intends to do with the page and whether it is a cross-origin or same-origin request. Basically, we don't allow cross-origin POST and SPA requests. We also don't allow JS initiated GET requests to DotVVM pages, use the config.Security.VerifySecFetchForPages option to disable this, if you rely on it.

If the browser does not send these Sec-Fetch-* headers, we don't check anything. You can enable strict checking by config.Security.RequireSecFetchHeaders option. By default it's enabled on compilation page to prevent SSRF and it does not matter too much if it does not work for someone with an obsolete or broken browser.

Improved server-side styles

Server-side styles is a powerful metaprogramming feature available since the early preview versions of DotVVM. However, we have significantly refactored and improved the API in this version to allow access to strongly typed properties.

Most of previous code should remain compatible, except for the SetControlProperty<TControl> method which should be replaced by .SetControlProperty(property, new TControl()).

Styles.Tag DotHTML property is introduced to allow easier matching to specific controls. For example, it may be used like this:

c.Styles.RegisterAnyControl(c => c.HasTag("prepend-icon"))
        .Prepend(new HtmlGenericControl("img").SetAttribute("href", "myicon.png"));

// or this rule applies to any descenant of a tagged control
// it will use <span data-bind="text: ..."></span> instead of knockout virtual element for each literal

c.Styles.Register<Literal>(c => c.HasAncestorWithTag("literal-spans"))
        .SetProperty(c => c.RenderSpanElement, true);

It is now possible to create controls in normal C# code and then put them into children, control properties or append/prepend them to the matched control. Use .PrependContent, .AppendContent, .SetControlProperty, .Append and .Prepend. You can also replace the entire control with a different one using .ReplaceWith which will also copy all properties onto the new control. Last but not least, you can use .WrapWith to place a wrapper control around it.

In previous version, it was only possible to set a constant value into the properties, now it's possible to compute the value for each control using a supplied lambda function:

// this will apply a confirm postback handler to all commands and staticCommands on this control
c.Styles.RegisterAnyControl(c => c.HasTag("confirm"))
    .AppendDotvvmProperty(
        PostBack.HandlersProperty,
        c => new ConfirmPostBackHandler(c.GetHtmlAttribute(
            "data-confirm-msg") ?? "This is a default confirm message")
        );

It is also possible to process a binding in the API. For example, this transforms every usage of the Visible property into a CSS class regardless whether it's a static value or a value / resource binding.

c.Styles.Register<HtmlGenericControl>(c => c.HasProperty(c => c.Visible))
        .SetPropertyGroupMember("Class-", "hide", c =>
            c.Property(c => c.Visible).Negate())
        .SetProperty(c => c.Visible, true); // reset the Visible property

The .Negate() is a extension method defined on the new ValueOrBinding<bool> type. There are many others including .Select(t => ...) where you can supply any lambda function which can be translated to a JavaScript binding.

Validation

We completely reworked the way validation works internally. Validation property paths are now always expressed as absolute paths from the root viewmodel to the affected property. Therefore, property paths always begin with the '/' character (expressing they are starting at the root viewmodel) and this character is also used to delimit individual path segments. Examples:

• /Customer/Id
  • this means that there is a property Customer in the root viewmodel
  • the error is attached to the property Id on the Customer.
• /Items/0/Price
  • this means that there is a collection Items in the root viewmodel
  • the error is attached to the element with index 0 o...

DotVVM 3.2

New features

Added more JavaScript translations

#1059, #1062, #1100
We continued with our effort to add JavaScript translations for common .NET methods and some custom extensions. You can use these methods inside data-binding to express more complex operations and have them evaluated on the client's side.

• DateTime property getters (e.g. Year, Month, Day etc.)
• WebUtility methods (UrlEncode(str), UrlDecode(str))
• Numerous new string methods
  • IsNullOrWhiteSpace(str)
  • Many overloads for comparing strings with the StringComparison parameter
  • Many trimming and padding method overloads

Improvements and fixes

Changed type of viewmodel to any

#1069
The type of dotvvm.state is now any. This allows for an easier access to the underlying state of viewmodels without the need of repeated casting.

Prefer to use state in static commands

#1078, #1113
We fixed a synchronization issue that occurred with state, which could have been observed using a staticCommand. Changes made to state in user code were not always correctly reflected. As a result it was possible to read old data using staticCommand.

Fixed OnPreInit invocation on DotvvmMarkupControl

#1082
Usage of the parameterless constructor on DotvvmMarkupControl may have previously caused weird issues in connection with the @js directive. This was caused due to the fact that the necessary resource was not loaded.

Fixed NRE when using NamedCommand without the @js directive

#1083
DotVVM no longer throws a NullReferenceException in case user specifies a NamedCommand without the @js directive. This use case is still not supported, however, DotVVM now throws a better and more descriptive exception that tells user what is wrong.

Improved error reporting when a function from viewmodule module fails

#1085
DotVVM now provides a better error whenever a function from a viewmodule (also known as a JavaScript module) fails.

Fixed issue with not loading assemblies with custom controls

#1087
Some users and components register controls using the config.Markup.Controls.Add(...) method call. However, this does not update the assemblies list in config.Markup.Assemblies and as a result DotVVM may have previously missed to load some necessary assemblies.

Fixed issue with type inferer

#1093
Type inferer for lambda parameter types no longer fails on some of the supported and more complex .NET methods.

Fixed REST API bindings generation

#1098
We fixed many issues in connection with REST API bindings generation. Generated code should now be correct and not dependent on the global Newtonsoft.Json settings. See also notes about breaking changes regarding this feature.

Fixed registration of viewmodules in markup controls

#1103
Viewmodules are now registered only for pages that have the @js directive. Previously the property that indicates whether a module is referenced could have been inherited by a markup control.

Fixed issue with indexing expression evaluating to null

#1120
DotVVM now generates expressions that are less strict whenever a null gets passed as an indexing expression, for example as a key to a dictionary. Instead of a compilation exception, it now propagates the null value as a result of the whole expression.

Fixed indexer's get method translation for dictionaries

#1121
We fixed an issue in the JavaScript translation for the indexer's get method for dictionaries.

Breaking changes

Behavior change after regenerating REST API bindings

Newly generated and regenerated bindings will have some changes. This is due to the fact that we had to update underlying Nswag version that changed the way API clients are generated. Most notably, there are the following differences:

• HttpClient is now cached and passed as an argument for the API client's constructor
• Generated code uses an ApiException instead of the previously used SwaggerException.

Users that do not regenerate their bindings are not affected by this change.

Tooling

Azure pipelines

#1067
Continuous integration system is now capable to run DotVVM tests both on Windows and Linux using newly defined azure pipelines.

DotVVM 3.1

New features

Added automatic detection for lambda parameter types

#936
DotVVM is now able to infer types of lambda parameters from the context the lambda function was specified in. This makes it possible to specify more concise lambda expressions. For example instead of a Customers.Where((CustomerDto c) => c.Id > 0) it is now possible to write Customers.Where(c => c.Id > 0).

Added support for custom extension methods

#946
We have extended the capabilities of the @import directive to also search for available extension methods within provided namespaces. This feature allows users to use their custom extension methods inside data-binding.

Added more JavaScript translations

#965, #1009, #1029, #1039
We added a lot of new JavaScript translations for common .NET methods and some custom extensions. You can use these methods inside data-binding to express more complex operations and have them evaluated on the client's side.

• Enumerable methods, string methods and Math methods
• List<T> methods
• Dictionary<K,V> methods

For a full list of supported .NET methods inside data-binding, see the following page from the documentation: Supported expressions.

Added support for string interpolation

#987
String interpolation is a well-known feature from C# that allows specifying a string prefixed with a '$' sign together with some interpolated expressions to be evaluated during runtime. Additionally, you can alter the way your interpolated expressions are converted into strings by providing optional formatting options. In DotVVM this is always a syntax sugar for calling string.Format(...).

Added support for dictionaries in viewmodels

#1014
It is now possible to use dictionaries in viewmodels. DotVVM now supports the usage of indexer in data-binding so that you can read values, change existing values, but also create new key-value pairs using the indexer on dictionaries.

Added support for passing AbortSignal into the postback

#1021
It is now possible to abort an in-progress postback. This can be useful to signalize if you already know that the result of postback is no longer needed.

HtmlGenericControl supports numeric and boolean values for attributes

#1028
Resource bindings previously supported only string values and collections of string in attributes. We extended this by supporting also: numeric types, bools, enums and Guids. DotVVM interprets booleans as indications whether a specific attribute exists or not. This means that an attribute is omitted when it is false.

Improvements and fixes

Fixed issues with assigning lambda functions to some known delegates

#936
Lambda functions can now be assigned to System.Actions and System.Predicates alongside with already supported System.Funcs.

Improved error reporting when a master page is corrupted

#976
Whenever a user makes a mistake while specifying a viewmodel for a specific master page, the error page no longer shows its type to be an UnknownTypeSentinel. Users now get a more descriptive error message that provides hints on how to resolve this issue.

Fixed generics resolving and method overloads search

#978
It is now possible to call more complex generic methods. Previously there were issues with matching generic parameters owned by types instead of methods, but also applying implicit conversions in some places.

FileUpload control does not need an iframe

#988
We have got rid of the iframe for FileUpload control. This makes it possible to use this control under more environments as we are aware that iframes can be discouraged by certain configurations.

Added helper functions for working with type metadata

#1013
We introduced a few utility functions to improve the experience when working with type metadata. You can find these functions under dotvvm.metadata when working with JS/TS.

Fixed serialization of byte[]

#1015
Byte arrays are no longer serialized as base64-encoded strings as this caused issues with coercing during deserialization.

Fixed RouteLink control with targets in SPA

#1016
SPA-routing logic is no longer applied on RouteLinks with targets that are specified within a SpaContentPlaceHolder. This makes it possible to use, for example target="_blank" to open a new tab from a SPA.

Updating non-existing array element should do nothing

#1020
Updating an array element from staticCommand after it was removed from viewmodel now does nothing. Previously it caused various issues when updating array elements with undefined values.

Warn when an uppercase attribute is used

#1022
Usage of uppercase attributes now generates a warning as it is likely a reference to a non-existing property. To silence these warnings, make sure to use all lowercase letters for standard HTML attributes.

Fixed issue with array and nullable types in lambda parameters

#1031
DotVVM compiler no longer throws whenever a user tries to create a lambda function with either a nullable type or an array type as one of its parameters.

Fixed compiler deadlock when building controls

#1035
We fixed an issue that made it possible to deadlock DotVVM compiler under special circumstances when building controls.

Better error messages for invalid resource name in @js directive

#1041
DotVVM no longer throws a NullReferenceException when the specified JS module is not found. We also improved error message for the case when the referenced module is not of ScriptModuleResource type.

Fixed issue with assigning to arrays and lists

#1052
DotVVM now correctly translates staticCommands that used indexer to change an element under a specific index.

Removed usage of culture-sensitive string operations

#1054
We replaced all occurrences of .ToUpper() and ToLower() calls with their culture-invariant alternatives. This previously caused some issues with, for example Turkish language.

Fixed compilation issues with extension methods

#1058
Repeated importing of the same namespace no longer ends with a compilation exception "Found ambiguous overloads of method ...". Additionally, DotVVM now correctly compiles extension methods that use default parameter values.

Fixed issue with assigning values to nullable types

#1071
Nullable properties can be assigned using either a nullable value or a non-nullable value (an implicit conversion should be used). We added the missing conversion that fixes compilation of the second case.

Tooling

Command-line interface

#872
Major rewrite of command-line interface and the stand-alone compiler executable. The compiler executable is no longer embedded in DotVVM NuGet package, but instead we introduced the DotVVM.CommandLine NuGet package.

DotVVM 3.0

New features

Calling JavaScript from DotVVM and vice versa

#935
We have added the new @js directive which allows to import a ECMAScript module in a page, master page or a markup control, and call its methods using _js.Invoke<TResult>("method", args...). Also, there is a new NamedCommand control which allows exposing DotVVM command or static command to the JavaScript code, so it can be called (including passing arguments). This allows easy interactions between DotVVM components and the world of JavaScript.

Variables are supported in binding expressions

#869
You can now declare variables in binding expression, which enhances the abilities especially in static command bindings — e.g. {staticCommand: var result = _myService.GetItems(); Items = result.Items; TotalCount = result.TotalCount}. The variable must be assigned immediately, and cannot be re-assigned to a different value (behaves similar to const in JavaScript).

Lambda support in binding expressions

#903
You can use lambdas in data-bindings, which opens many new possibilities, for example calling LINQ methods or expose command bindings to JavaScript code that can get custom parameter values.

New client-side event initCompleted

#915
This event is called after the viewmodel is applied to the page DOM.

Additional metadata can be returned with the command result

#916
This allows returning additional information together with results of command or static command calls. This information can be read e.g. in the afterPostback event or in a postback handler, and used to perform any client-side action (displaying an alert, custom validation, and so on).

Extension methods are supported in binding expressions

#931
Right now, we only support few white-listed extension methods from System.Linq namespace, but we'll allow to call any extension method based on @import directives in DotVVM 3.1. This is already implemented in #946, but the PR is still being reviewed so it didn't make it into 3.0.

NPM package with TypeScript definitions

#952 #956
If you want to write TypeScript code that interacts with DotVVM, you can now use the dotvvm-types package.

DotVVM uses non-minified version of scripts when config.Debug is true

#970
This helps with debugging script errors by peeking into non-minified DotVVM code.
Minified version of DotVVM has now about 48 kB, plus 69 kB for Knockout JS. With HTTP compression enabled, the total download size of DotVVM and Knockout together is ~55 kB. Make sure you don't deploy your apps to production with the debug flag — the debug scripts are significantly larger.

Verbose client-side logging flag

#971
If you want to see more detailed logs in the dev console, create a dotvvm-loglevel entry in the local storage of the site and set it to verbose. DotVVM will emit information about client-side events, and more.

Improvements and fixes

Refactoring of the client-side part, migrated to the modern TypeScript, rollup bundler.

#834
All client-side code of DotVVM was refactored and now takes advantage of the newest TypeScript language features (ES modules and so on). We are using rollup to create bundles for modern browsers as well as for Internet Explorer 11. We also have different bundles for SPA and non-SPA pages (non-SPA are slightly less).

Client-side events and postback pipeline

#885
We have reviewed and thoughtfully refactored the postback processing pipeline, fixed many issues, and resolved several inconsistencies (for example: some client-side events didn't get all arguments that one would expect, and the internal implementation of error handling was not very straight-forward and maintainable). See the Breaking changes section — there were some API changes which may affect you.

JavaScript tests migrated to jest

#883
We now have much more client-side tests as well as stress test which help us detect race conditions in postback concurrency handling.

Multiple SpaContentPlaceHolder controls can be used on the same page

#847
We have also removed the old format of SPA with the hashbang (#!) construct in the URL in favor of History API which is supported even in IE 11. The DefaultRouteName, PrefixRouteName and UseHistoryApi properties are deprecated — History API is used by default, and it's the only option. The links in the old format will still work — DotVVM will redirect to the new URL format.

Viewmodel state is represented by an immutable JavaScript object

#884
The state of the viewmodel is not kept in the hierarchy of Knockout observables, but in a new state manager's immutable object. The hierarchy of Knockout observables is still there, but it is “virtual”. Every change via Knockout observables will patch this immutable state, and the changes propagate asynchronously to all affected places in the Knockout observable tree. It helps to create a similar effect as deferred option in Knockout. The state manager offers new API which lets you access the viewmodel without messing with observables (state property, setState and patchState functions).

Improved resolving of generic methods and overloads for custom JS translations.

#892 #937
From version 2.0, DotVVM offers to supply custom C# to JS method translations. We have fixed some issues and enhanced the method matching to support generic arguments, param arrays, and more.

Type-safe viewmodels

#905
DotVVM passes type metadata alongside the viewmodel, so we can make sure the viewmodel won't allow assigning e.g. array to a property of string. DotVVM checks all assignments to the viewmodel properties against this type definition, and throws errors in case of type mismatch. In some situations, it can coerce the value to the correct type (e.g. number to string).

Static commands can be passed to markup controls

#928 #943
Markup controls did allow passing value and command bindings from the outside, but it didn't work for static commands.

Route redirection helpers enhancements

#938
You can modify query string arguments when you use AddRouteRedirection feature introduced in DotVVM 2.5.

Markup files can be referenced from a directory outside the application directory

#908

Fixed bug in static commands with multiple server calls

#910

Progress in our effort to use non-nullable reference types

#912

Fixed URL-encoding problems in RouteLink parameters

#922

Customizable active and disabled CSS classes in DataPager

#923

Fixed issue with async command execution

#933

Progress in making our UI tests more reliable

#949
We have introduced retry logic into our Selenium test helpers which will help us clean explicit waits in our tests. Thanks to this, the tests will hopefully be more readable, easily maintainable, and reliable. Right now, it is common that from the hundreds of UI tests, one of two just fail randomly — that's why the build status of DotVVM is often shown as failing.

Fixed culture-dependent letter case conversion to invariant in the serializer

#951
This was a community-authored PR which helped us realize that we have to consider the culture invariancy every time when ToUpper/ToLower is used. "I".ToLower() resolves to "i" in most cases, but in Turkish it is "ı". Many thanks!

Fixed bug in concurrency handler in static commands

#957

Breaking changes

Null propagation now passes nulls into methods

#817
Previously, any binding expression which evaluated to null caused to evaluate the parent expression to null as well. If there was a method call in the expression, and any of the arguments evaluated to null, the entire method call was skipped and evaluated to null. We changed this behavior so the null is passed in the method.

Script resources use defer by default

#930
DotVVM resources was marked as deferred, which means that all other scripts that depend on DotVVM need to be deffered too (otherwise, they would load before DotVVM and fail). We have changed the default behavior of ScriptResource so the Defer property is true by default.

Async IUploadedFileStorage and IReturnedFileStorage

#981
We changed these interfaces to use async methods everywhere. The behavior hasn't changed, you'll only need to add await to the GetFile or ReturnFile calls.

Type-safe viewmodels

#905

• Objects in the viewmodel now always have the $type property which contains unique ID of the concrete type. When object without the $typeannotation is added in the viewmodel, DotVVM will infer the type automatically.
• Properties of type DateTime are now validated (even if there is noRequired attribute). From DotVVM 3.0, empty date values won't be sent to the server.
• If you call dotvvm.serialization.deserialize or dotvvmserialization.serialize methods in the client-side DotVVM, consider replacing them with the new state manager API (state property,setState and patchState functions on the observables). You can also assign plain JS objects to the viewmodel observables — they will be coerced automatically. We plan to remove the serialize anddeserialize methods from the public API in the future versions.

Client-side events and postback pipeline

#885
Due to the refactoring and cleanup, most of the client-side events had some changes in the structure of event arguments (new properties were added).

• error — we have removed the isSpaNavigationError flag, and we have added a new event spaNavigationFailed that is fired in case of SPA navigation failure (network error, exception on page load etc.)
• afterPostback — we have removed redirectPromise and handled parameters
• spaNavigating — the newUrl parameter was re...

DotVVM 2.5

This release includes all changes from DotVVM 2.5 Preview 2, as well as a few additional improvements:

Features

• #880 - Inline editing is now supported in nested GridView controls
• #890 - DotVVM uses its own JsonSerializerSettings and doesn't rely on DefaultSettings
• #877 - Control developers now may create attached property groups (e. g. <element MyExtensions.SomeGroup-SomeKey="something" />)
• #896 - The AddDotVVM and UseDotVVM methods now allow passing a custom instance of the DotvvmStartup class so it is possible to set its properties and so on. If you plan to use this feature, we recommend keeping a default constructor - otherwise, the DotVVM Compiler (used by the Visual Studio extension) will be unable to create the instance of this class.

Fixes

• Fixed references to netstandard in view compilation - these didn't work on older versions of .NET Framework.
• Fixed deadlock occurring on the first HTTP request on OWIN.
• Fixed incorrect invocation of the beforePostback event on static commands.

Enhancements for framework developers

• #874 - Infrastructure for end-to-end testing without the need of using Selenium.
• All paths are using forward slashes so everything in the repo should work on non-Windows machines.