LiveView - Streaming Rendering patterns

To successfully convert a Windows Forms application to a Web application without needing to decouple the ViewModel or extract an API, we combine the LiveView and Streaming Rendering patterns.

• LiveView Pattern: Enables real-time, interactive UIs by maintaining a persistent connection between client and server. The server handles rendering and logic, sending updates as the application's state changes, allowing dynamic content updates without full page reloads or extensive client-side JavaScript implementations.

• Streaming Rendering: UI content is sent from the server to the client in small chunks as it’s generated, allowing users to view and interact with parts of the page immediately. This approach enables dynamic updates to specific portions of the page in response to user commands and asynchronously to internal parallel processes or external events.

By applying such patterns, we switch the Application architecture from this:

To this:

Our modernization process replaces the Windows Forms native OS rendering system with an HTML server-side renderer. The modernized architecture includes the following components:

• Client Proxy: Relays raw HTML events to the server and updates the DOM based on the visual deltas sent by the server.

• Full-Duplex Connection: Asynchronously streams commands and visual updates in near real-time.

• Original Application Logic: HTML events are mapped to Windows Forms events and programmatically triggered in the original application logic. This initiates one or more business logic processes that modify the application state.

• HTML Renderer: Directly bound to the application state, it reacts to its changes by generating new HTML code and computing the difference from the current visual state. Only this difference is sent back to the client.

[Introduction: Write a short introduction for this.]

High Coupling

A typical legacy application is usually highly coupled. The design of Windows Forms components favors the proliferation of several antipatterns, such as business logic being directly written in button events, models being used as view models, and the lack of clear architectural layer separation.

Standard Approach for Modernizing Web Applications

Modernizing a legacy Windows Forms app to a standard Web application normally involves two expensive and time-consuming steps:

1. View Model decoupling: Modern web frameworks divide business logic (server) from presentation logic (client). From a Windows Forms perspective, this requires extensive analysis and the rewriting of most of the graphical logic.

2. API Extraction: A high-level API must be designed to serve the client application. This requires a deep understanding of the business semantics and full access to a domain expert.

It is important to note that Blazor Server operates as a stateful service, where all session data is maintained in the server's memory. In scenarios with multiple users, horizontal scaling may become necessary. Since Blazor utilizes persistent WebSocket connections, the scaling infrastructure must be capable of maintaining these connections and correctly routing messages to the appropriate instances that manage the user sessions. Additionally, the system must handle reconnection logic to ensure session continuity when disruptions occur.

Session Affinity

Session affinity, or "sticky sessions," is a crucial routing mechanism in Stateful server-side applications that ensures all requests from a specific user are consistently directed to the same server instance, particularly when scaling out.

Session affinity guarantees that all SignalR messages are routed to the same instance. This approach also automatically manages reconnections when necessary.

The following diagram outlines the services that offer WebSockets session affinity, along with the deployment options for scalable back-end infrastructure across the major cloud providers (AWS, Azure, GCP). Service selection should be driven by your specific technical requirements:

Although any major UI design pattern, such as MVC or MVP, can be implemented in Blazor, it is especially well-suited for the MVVM pattern:

1. DOM event: The user triggers an event (e.g., 'onclick').

2. Event relayed to View Model: Using a WebSocket connection, the event is sent to the server and then to the session View Model.

3. State change: The View Model executes business logic and updates the model.

4. View Model update: The View Model reacts to model changes, updating its state and triggering the HTML renderer.

5. HTML rendering: The HTML renderer uses the bound parameters from the Model to generate new HTML and compute the difference with the current state.

6. Visual delta transport: HTML differences are streamed asynchronously to the server, reducing data transfer and improving performance by updating only the necessary elements.

7. DOM update: The view is refreshed by directly modifying the DOM with the received data.

The modernization process converts a legacy Windows Forms application into a Web-based application, stored on a remote server and delivered over the Internet through a browser interface.

This has the following advantages:

• No installation required.

• Not limited to Windows OS.

• The resulting App uses Cutting-edge web frameworks and patterns.

• Can be distributed and billed using a SaaS model.

• [more?]

Our Modernization process has the following goals:

• Business Logic retention: Most legacy software is a 'black box' in terms of the inner workings of its business logic. Our modernization process does not require any major analysis, refactoring, or reimplementation of existing Business logic.

• Maintainability: The output of the Modernization process is a set of software projects that can be considered software products on their own. Unlike many other transpilers, the resulting code is intended to be human readable and modifiable.

• Extensibility: The modernized codebase is intended to be easily extended by seamlessly interfacing with third-party Web Component libraries and new business logic implementations.

• [more?]

To illustrate how we use Blazor to modernize Windows Forms applications, we will use this simple example:

In this scenario, when the button is clicked, the model (Counter) is updated, and the UI automatically reflects the changes.

Upon the successful completion of our Modernization process, the expected outcome will be as follows (the code has been significantly simplified for clarity):

• The original Windows Forms code remains essentially unchanged, with only minor modifications to accommodate the distinct characteristics of a desktop application to a server-side application.

• Razor components, along with their associated bindings and observers, are automatically generated as part of the modernization process. There's no need for you to create or modify this code manually.

• Bindings and observers trigger Razor components to generate HTML dynamically as needed. This HTML is then transmitted to the client, where the DOM is updated in real-time via Streaming Rendering, aiming to provide an experience as close as possible to that of a desktop application.

The following diagram details the execution flow triggered when the button is pressed:

Modern web browsers have strict security restrictions preventing direct access to hardware. Even with physical access, browsers block such connections. In some cases, hardware may be in a remote facility, unable to connect directly to the user’s machine.

Hardware devices must connect to an Agent running on a local computer or embedded device, acting as a bridge to the Blazor app. The device can be remotely controlled and send real-time telemetry to the user. This follows standard IoT principles, enabling remote monitoring and control over a network.

Scaling Blazor apps with multiple hardware device connections across servers presents routing challenges, especially with many-to-one or one-to-one user-device mappings. Load balancers with sticky sessions ensure the session stays on the same server, while message routing mechanisms ensure control commands and telemetry reach the correct user-device pair.

Different cloud providers, such as AWS, Azure, and Google Cloud, offer various solutions for achieving scalable, reliable communication between users and remote hardware devices. These solutions often involve message brokers, event routing services, and IoT platforms:

Guide to understand Solution Generator task

Problem

One important challenge in the upgrade from Desktop to Web application is the handle of the static variables, in this scenario, the Desktop application only have one scope, if you execute multiple instances of the same application each one will have its own context, in Web application there are different scenarios.

For example, in Blazor WebAssembly deploy it will create one scope per tab or SignalR connection, so it won’t require any change given is a similar execution mode.

In Blazor Server we only have a server-client architecture so, It'll be the same server handling different connections, the scope of the static variables are global, so if you as a user open different tabs, they’ll share the same static variables and values, not per session/tab as expected. As we can see in the following diagram the life cycle of a static variable will persist during the whole server execution.

Solution

After some research of different approaches a StaticService is implemented, this service is global and will store the value of the static variable per session, handling by itself the session and the storage. It will give us the following methods:

• Get which will return the value stored in the service for this static variable.

• Set will set the value into the service for this static variable.

• InitializeData, when we have a static property auto-implemented in the source code with a default value, we need to keep the value, but C# doesn’t allow non-auto-implemented properties to be initialized, so this method will set the corresponding value to the property in the first call on Get.

This service will involve changes on the conversion of the static variables that we’ll review in the following section.

Conversion Changes

This feature implies that we need changes in the converted code, principally on the getters and setters, each one will require to call the methods. One important decision we made during the design of this feature is to keep the code visible instead of using some attribute in order to increase the visibility and the maintainability of the converted code. Here we have a basic example with no initialization:

Winforms:

Blazor:

There is another example when an initialization is set on the static variable.

Winforms:

Blazor:

Service Setup

The StaticService requires some configuration in the program of our new application, is necessary to add the Session, DistribuitedMemoryCache service, HttpContextAccessor and initialize the services as we can see in the following code:

These services are required to be provided to the StaticServices to handle the different sessions and identify which one is the current session that is being consulted.

Problem

Working on the implementation of the ImageList, we encounter the issue of management of resources through the ImageListStreamer. The ImageListStreamer is basically a serializer of all the images that are stored inside the ImageList component.

This ImageListStreamer is initialized by the .resx file associated with the .designer in which the ImageList is created. The .rex is the one that created the instance of the ImageListStreamer, serialized in base64 all the images and associated the data with a specific public token and the System.Windows.Forms.ImageListStreamer class.

This makes it very difficult to use this data to serialize out of the implementation of the WindowsForm component because it always needs the .dlls hashes to validate the information. This means that any custom implementation of the ImageListStreamer out of WindowsForm will fail when it tries to convert or deserialize the information storage in the .resx file.

Work around

As a way to interpret this mechanism through the resource, we manage to find a work-around that uses the same resource to get every image and storage in the ImageList array. Basically, the ImageList creates an instance of the ImageListStreamer and inside this, creates a method that takes the resource as a parameter and, having stored the keys for every image, gets the object Image associated with the key.

The problem with this solution is that it needs changes in the migrated code like the call of this method that fills the ImageCollection or adds every Image manually to the .resx file and associates that image name to the key so the resource can find it when it is searched.

Possible Solutions

A possible way to manage this issue is to create a pre-serializer that changes the values that reference the System.Windows.Form.ImageListStreamer for our implementation. That might let us create an instance that references the ImageStream in the .resx file and serialize normal inside the Blazor.ImageListStreamer.

Another solution is to somehow decode the images inside the ImageStream and storage separate in the .resx files of the migration project. This will help us with the work-around to minimize the manual changes in case the first solution does not work.

The Application All Applications of any Desktop Compatibility Platform should associate the Forms with the corresponding IApplication implementation.

The Application All Applications of any Desktop Compatibility Platform should associate the Forms with the corresponding IApplication implementation.

<mapfrom>System.Windows.Forms.Application.</mapfrom>

Releases unmanaged and - optionally - managed resources.

Parameters

Removes the active form.

Parameters

Gets or sets the active form.

The active form.

Gets or sets the active forms.

The active forms.

Gets the current application.

The current application.

Gets or sets the item has changed.

The item has changed.

The documentation for this class was generated from the following file:

• src/Gap.Blazor/Controls/Application.cs

This document helps to understand the SolutionGeneration task, starting from the ProjectGeneration to the WFNetConversionTool call and settings to execute the Generation service.

First thing to understand is what ProjectGeneration does. ProjectGeneration contains the services and templates that generate the output files for a project, using some configurations. In this file, we will be focusing on the SolutionGeneration for Blazor.

We need to start talking about the Interfaces of the Abstractions. This interfaces define the properties and methods needed to execute the generation of the project.

We can find the interfaces in the Mobilize.ProjectGeneration.Abstraction project under the SolutionGenerator repository.

Go to IProjectGenerator, we can find some properties. You can see this properties as parameters that the Generate task needs.

Pay special attention to this method definition, because this will be called inside the Task to call the generator you need.

Now that we see this Interface, we need to understand… Why is this needed? Well, let’s jump on it.

Under the same project, we have a class called ProjectGeneratorBase.

This class implements the IProjectGenerator interface. If you navigate a bit in this class, you will find the GenerateProject implementation.

Now, we need to use the template used by the respective GenerateProject. In this case, we should go into the SolutionTemplate.tt.

Avoid touching the SolutionTemplate.cs

You can modify the template as we did here.

And save the file. When you save, a popup is showing. Press Yes. This is to synchronize the tt with the cs(the cs is generated dynamically by handlebars).

Pack the projects as a nupkg

To test the changes we can pack the projects locally, or, upload the changes to a branch and wait for the build to generate an alpha version.

To pack locally just run the next command under the build folder. Change the path for every csproj

nuget.exe pack 
S:\Repositories\EF\EF-TransformationCore\src\Mobilize.ProjectGeneration.Abstractions\Mobilize.ProjectGeneration.Abstractions.nuspec -version 22.33.11 -properties configuration=debug

Test the changes

Once you pack the changes, you need to install the package in the WFNetConversionTool. If you pack it locally, add the build folder to the package sources in the Nuget Package Manager of Visual Studio.

Or install the alpha version if you commit the changes to a branch.

Changes in the WFNetConversionTool

Now, is necessary to add the BlazorSolutionGenerationTask and the BlazorSolutionGenerator

Here we have our BlazorSolutionGenerator, that will set the params and config to call the GenerateProject from the ProjectGeneration.

Here in the Run method, we need to pass the config to the SolutionGenerationParams

And now, we can call the BlazorSolutionGenerator from the Task.

This are release notes and versioning for WebMap for Blazor:

This Beta version of WebMap for Blazor includes the following release features:

Desktop Compatibility Platform (DCP)

The DCP support is focus on basic and complex controls requires for SKS demo controls like:

Mapping Framework

To generate mapping events and models for C# .Net control to Blazor control we use Telerik library framework to create custom control maps.

Telerik UI for Blazor version 6.2.0

Features Implemented

• Static variables management status: since in a web environment static variables represents a restriction on the sessions that can be created / accessed this reduce the capabilities of the tool, so we create a mechanism to map static variables as services assign.

• .Net9 Framework outcome: our applications conversion results use references for .Net 9 Framework to use latest version of supported framework.

• DataGridView support: initial challenges on conversion are Grids management so we support basic methods, properties and events required for DataGridView.

• Mdi Forms conversion: emulate the winforms Mdi behavior of encapsulation of forms and allow navigation with several screens.

Blazor is a powerful framework from Microsoft that enables the creation of interactive web applications using C# and .NET technologies, providing an alternative to JavaScript. It seamlessly integrates with existing .NET libraries and tools, offering a rich selection of visual controls to support modernization and extension of your legacy Windows Forms applications.

One of its standout features is the implementation of LiveView and streaming rendering patterns, making it an ideal choice for modernizing legacy applications.

The main advantages of using Blazor for modernization are:

• Rich interactivity in C#: Handle arbitrary UI events and implement component logic entirely in C#, a language that is very likely to be familiar to your current development team.

• Single Tech Stack: Your application will be implemented using a single tech stack, enabling you to build both the frontend and backend using a single codebase.

• Efficient UI-Delta based Rendering: Blazor optimizes UI updates by carefully tracking changes in the DOM as components render, ensuring that updates are both rapid and efficient.

• Ease of Debugging: The step-by-step debugging and Hot Reload features significantly enhance development efficiency.