.NET to the Core

.NET foundation enabling multi-platform deployment and dynamic assembly generation

Platform → Technology → Core → Real-Time | AI-Ready | .NET | Native | UNS | Python 

Component TFM Summary

Each FrameworX component targets the .NET flavor that best fits its role:

The split is deliberate: the Designer leverages mature Windows desktop tooling on .NET Framework 4.8, while the Runtime gets the performance, footprint, and cross-platform reach of modern .NET. The portable Kernel keeps both sides aligned on a single object model.

Script Compilation Target

Script Tasks, Script Classes, and Display code-behind are compiled by the Designer, on the Windows machine where the Designer runs. For server code, the compilation target follows the Target Platform of the solution, not the framework the Designer itself runs on. Display code follows the client that runs it, see Display Code-Behind and Client Code below.

This also applies when the Designer is connected to a remote solution server, for example a Multi-Platform solution running on Linux. Compilation still runs on the Designer machine and the server only executes the compiled output, so the matching .NET runtime is required on both the Designer machine and the server.

The C# language version comes from the compiler included with FrameworX, not from the .NET runtime installed on the machine. For VB.NET, the equivalent levels are VB 15.5 on .NET Framework 4.8 and VB 16.9 on the cross-platform target.

Display Code-Behind and Client Code

Display code-behind and display expressions are compiled once for each client type. The client that runs the code decides the target, in both Windows and Multi-Platform solutions:

WPF clients always run on .NET Framework 4.8 and only on Windows, even in Multi-Platform solutions where the server runs on Linux or in Docker. The same code-behind can build for HTML5 and fail for the WPF clients, so code shared by both client types must stay within C# 7.3. Script Classes that run on the WPF clients follow the same rule.

C# 7.3 Compilation Errors

In Windows solutions, and in any code that runs on the WPF clients, newer C# syntax is rejected with error CS8370: Feature '...' is not available in C# 7.3. Common examples are using declarations (using var x = ...;), switch expressions, record types, the range operator (..), default interface methods and top-level statements. Use the C# 7.3 equivalent, for example using (var x = ...) { ... }.

Changing the Target Platform of a solution is a migration, not a setting. It is done in Solution Settings and requires a Build All before the solution runs again.

Multi-platform Deployment Options

Choose the cross-platform runtime as default unless you need specific .NET 4.8 libraries or zero-installation Windows deployment. 10.1.4 and 10.1.5 can be installed side-by-side on the same machine as isolated runtimes.

100% Managed Code Benefits

Being entirely managed code provides industrial-grade reliability:

• Intrinsically safe software - Cannot cause system crashes or memory corruption
• Automatic memory management - No memory leaks from user code
• Process isolation - Scripts run in separate application domains
• 24/7 operation - Garbage collection without stopping the system

This architecture prevents the cascading failures common with native code in industrial systems.

Dynamic Assembly Generation

The built-in code editor doesn't just compile scripts—it creates new .NET assemblies on the fly:

• Runtime component creation - Generate new functionality without restarting
• AI integration capability - MCP tools can create custom methods dynamically
• Solution-level customization - Extend the platform using only built-in tools
• No external dependencies - Complete compiler toolchain included

This unique capability enables advanced features like AI-generated configurations and runtime optimization that would be impossible with traditional scripting.

Native .NET Objects Throughout

Every project element is a native .NET object accessible via IntelliSense:

• Tags, alarms, and datasets as first-class objects
• No temporary variables or type conversions
• Direct data movement between tags and DataTables
• Full object model exposed to scripts

Execution Model

Server-Client Separation

The platform automatically manages execution distribution:

• Server-side - Global logic, data processing, device communication
• Client-side - UI interactions, local calculations, display logic

Developers create sophisticated applications without managing this complexity—the platform handles it transparently.

Tasks, Classes, and Expressions

• Tasks - Scheduled or event-driven processes
• Classes - Reusable .NET libraries and components
• Expressions - One-line calculations with full .NET access

Process Isolation

Each script runs in its own application domain, isolated from the real-time database for maximum security and preventing any script from affecting system stability.

Development Environment

• Languages - Industry-standard C# and VB.NET
• Code translation - Convert between languages anytime
• Full debugging - Breakpoints, step-through, watch windows
• Online changes - Modify and debug while running

Related Concepts

• Object model leveraging .NET types
• In-memory database using .NET collections
• Cross-language capabilities
• Platform Generations - Evolution of the .NET foundation

In this section...