Page History

This page contains the article High Availability and .NET Framework

Introduction

One feature that remains unchanged in mission-critical and industrial applications is that operational stability, safety, and security are its principal requirements. The mechanisms related to increasing the guarantee of stability are among the core architectural changes made possible by new technologies, specifically in software. The advent of the Microsoft .NET Framework

introduced higher and unique features

for creating high-availability systems.

.NET features

, including productivity tools, development

aids, class libraries, and communication standards

, play a crucial role in improving a Project Development Platform. However, this article

focuses on two important areas that

.NET

manages particularly well:

1. Creating

1. Intrinsically Safe Software Architecture
2. Managing

1. Multiple Versions of Operating Systems, Software

1. Tools, and

1. Projects

Software Safety

Intrinsically Safe Software

In field instrumentation, security is not only guaranteed by internal procedures or manufacturers'

warranties but also

primarily by the system architecture,

which uses voltages and currents

that are "intrinsically safe" in the environment

where the instrumentation will operate

. This ensures that even in

the event of

specific equipment failure, the system

remains protected.

When we

began using the

term "intrinsically safe software,"

we

received many questions about its meaning

in the context of software. It

refers to

applying the same concepts we have in hardware to software systems. Specifically,

even

if a software component

fails, the system architecture and design should have intrinsic protection

to ensure safety and

operational integrity.

The previous generation of technology

relied on C/C++, pointers, and several modules sharing the same memory area, with direct access to hardware and

operating system resources. These methods,

while necessary at the time

, are considered intrinsically unsafe by today's standards.

New Generation x Previous Generation

The new generation of software

utilizes computational environments

such as the .NET Framework, where processes are natively isolated

from each other and the operating system, regardless of the programmer

. This approach allows for better utilization of computers with multiple

processor cores and

ensures higher operational stability, even in the face of potential

driver and hardware errors or failures

in individual

system modules. This also applies to user scripting

within applications.

Previous generations

relied on proprietary scripts or interpreted languages, such as JavaScript, VBScript, VBA, or proprietary

expression editors

. The new generation

leverages modern

, compiled languages

like C#

and VB.NET,

offering control

over exceptions, multi-threading, enhanced security,

object

orientation, and

better execution control.

Interpreted languages do not allow for full code validation during

development phases

. Validation occurs only when the code is executed,

meaning many

issues are

discovered only during

project execution

,

not during

technical configuration. A typical project may have hundreds to thousands of

potential execution paths for the code, and

exhaustive testing

of all these paths

is not feasible.

The ability to detect potential errors during

engineering and

to recover and isolate

errors during runtime are

critical for safety and operational stability

. This level of assurance is achievable only by migrating legacy interpreted scripts to

newer compiled and managed languages.

Releases and Compatibility

High Availability

An important

consideration regarding high availability is how to manage

new

releases and system life-cycle management.

In

practice, most systems require updates, corrections, and enhancements after their initial deployment

. One of the most common factors that

jeopardize a system's availability

is

change management. Even if the application itself

remains unchanged, installing new computers, updating operating systems

, and applying software tool updates

can affect system stability.

During the initial development of our platform, we spent many months studying how to better manage

this issue

and how virtualized programming environments

like .NET and Java could

assist in achieving this goal.

Ultimately, we discovered that

starting from a clean design

allows for embedding architectural components

that facilitate future releases and updates, thus improving the management of system changes and maintaining high availability.

System Availability

The .NET

platform has proven to be a highly effective execution framework due to several advantages, including support for multiple programming languages, easier integration with Microsoft server and client components, faster and more

advanced graphical tools,

and a highly productive development environment, among

other benefits.

Leveraging the features of the .NET platform

, this article will explore three techniques used to ensure maximum compatibility and system availability, even in

the event of new releases of .NET or

applications using deprecated classes or methods

. These techniques are:

• Application layer on top of Microsoft .NET Framework

• Built-in Microsoft .NET compiler supporting multi-targeting

• Leverage side-by-side execution 

Using consolidated technologies, such as SQL

databases, to store

application programming and configuration also helps

maintain backward compatibility

as the product evolves. However,

this article will focus on explaining the three

techniques most relevant to new .NET versions and potential deprecated methods.

Application Layer on .NET Framework

Independent Application Layer

The first design requirement is to ensure that the

software tool used to create the application is entirely in .NET

managed code. For

instance,

our version 2014.1 was fully developed in C#

using .NET Framework 4.0. The

concept

involves using the software tool to create

final application projects,

exposing most

functionality not

as

low-level platform

calls but as an "Independent Application Layer."

Let us explore and understand this concept.

Except for

user scripts that may include direct .NET

calls—discussed in the next

section—the remainder of the software

tool’s functionality is designed to avoid exposing .NET directly to the engineering user. Instead,

it presents a higher-level configuration tool

.

Consider displays, drawings, and animations in our platform. Instead of

requiring application engineers

to delve into .NET programming,

the platform provides a higher-level interface

for enabling dynamic properties

through dialogues and internal deployment of those

features

. Users

interact with high-level drawing and animation tools rather than dealing with WPF, XAML, or .NET programming

.

Thus, when an internal .NET

class is changed, the software can

maintain the same user settings but internally implement the feature using the new .NET classes.

This approach allows us to create

display

drawings that

run natively

on both Microsoft .NET WPF and Apple iOS Cocoa.

Example

Let us use the example of the "Bevel Bitmap effect," which was deprecated in version 4.0, to illustrate this concept. Assume your application was using

this effect.

According to

the concept,

rather than implementing the Bevel effect directly in user programming code, you would have a "Configuration checkbox to enable Bevel dynamic" available in your "DYNAMICS"

interface—similar to the "SHINE - Outer Glow effect."

The user would select

this animation

for an object, and the implementation would be

handled internally by the software configuration tool.

When the Bevel method is removed from the .NET Framework, the software package would replace the deprecated implementation with another method or library

that mimics the same visual effect

as

closely as possible,

even though the internal deployment

differs.

This approach ensures that the user experience remains consistent, despite changes in the underlying technology. The same

concept applies to other potential issues.

By having an abstraction layer between your project development and the platform

, you

can maintain project compatibility and manage necessary changes internally. This makes it possible to

keep the

project configuration compatible with future .NET releases

in a way that is transparent to application engineers.

anchor_GoBack_GoBack

Multi-Targeting

Code Generation and Compiling Classes

Another

significant advantage of the .NET platform is its support for code generation and compiling classes, which

allows embedding a full .NET compiler within a Project Configuration tool.

This capability provides complete control over how

the system parses and compiles user-created scripts, including the option to compile the code

for different versions of the Microsoft .NET Framework.

By default, the system will compile

application scripts to match the

.NET version used by the latest software tool

, running them within their own AppDomain.

Additionally,

this control

allows the system to compile scripts to an earlier .NET Framework version if necessary.

Operating System Independency

With .NET 8, you can run the exact same code on Linux, macOS, and Windows computers. 

Example

Let us explore a case scenario: imagine that you have a system created in Microsoft .NET version 4.0, and you

need to migrate the system to a new .NET release 4.X. For this discussion, let us assume the application you created had scripts

using methods that were deprecated

in the updated .NET Framework. What now?

There are two solutions for

this:

• Solution A — If the deprecated method was replaced by another similar enough to be replaced automatically, the Project Configuration tool may have

• an Upgrade Utility to locate those methods in the code and replace them with the new

• ones automatically.

• Solution B — The project configuration tool can

• allow users to select the .NET TARGET of the project scripts.

• Just as Visual Studio can create DLLs

• for .NET 2.0, 3.5, 4.0, or 4.5

• based on

• user selection,

• the embedded .NET compiler

• within the Project Development tool can use similar features. Therefore, if necessary, we can enable your project to

• compile the scripts in both

• distinct .NET versions, even

• when using the latest software configuration tool, according to the user's selection of the TARGET. It is possible to have the same project running side-by-side with some script tasks under 4.0 and

• others under 4.X, as we will see in the next section.

Side-by-Side Execution 

Multiple Versions

Finally, .NET has a potential feature that must be leveraged in a Project Development Platform design: it can run different versions of the same component simultaneously or have multiple processes using

different

versions of the .NET

FrameworX running concurrently.

Using, for example, the core components

included in our platform's project management and user-interface services,

different versions of the product can run concurrently on the same computer. Furthermore, when running one project, the

various modules, real-time database, scripts, and communication

components do not run in the same Windows processes; they are isolated in their

own processes, exchanging data

via a WCF (Windows Communication Foundation) connection.

Similarly, device communication

creates

a separate Windows Process (one .NET AppDomain) for each protocol

, which can also apply to different user scripts in the

project—one compiled and running for .NET 4.0

, and another

for other releases. Both processes run side-by-side, with no conflict, each

in its own domain, and both accessing

real-time tags on the server process.

32 and 64 bits

Another similar scenario is the feature that

allows us to manage 32-bit and 64

-bit execution

within the same project configuration.

By default, when installed on 64-bit computers, a .NET application will leverage the operating system platform

and run all its modules natively in

64-bit mode when

installed on 64

-bit operating systems.

However, sometimes

you

may need to force

a specific script,

communication driver, or even the

graphical user

displays to run in 32

-bit mode.

For instance, if you

are using an external code DLL or a graphical component from a third party

that only works in 32

-bit mode, we

provide a RunModule32.exe version to allow

that specific project

component—such as

scripts,

displays, or

device communication—to run in a

32-bit process, while the rest of the application

runs in 64-bit mode. The communication between

these processes uses WCF, ensuring

complete isolation among the processes.

Reliable Application

Creating a reliable application that is manageable on throughout its life-cycle is of ultimate importance lifecycle is crucial and one of the top benefits of using .NET and creating new Software Tools to build new software tools from the ground up instead of , rather than migrating previous code, having . Designing a Project Configuration package that had its very first design with the goal to leverage the of leveraging currently available technologies is essential.

Even though this new technology is availableDespite the advancements in technology, many systems still rely on code ported from DOS or using use Windows low-level APIs and previous versions that create older versions, which can lead to the DLL-hell effect of Windows, where any update, any installation of another in Windows. This situation occurs when updates, installations of unrelated software, any change or changes in any part of the system , could can break it alleverything.

Using By utilizing the right features provided by the .NET Framework, SQL databases, and adding incorporating a well-designed "Independent Application Layer," , you can create systems that have maintain high compatibility with previous applications but cannot deny the ability to keep evolving the feature set and the while continuing to evolve in terms of features and technology.

In this section...