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 Microsoft .NET Framework brought higher and unique features to create high-availability systems.

.NET features regarding productivity tools, development help, class libraries, and communication standards

with a crucial role in improving a Project Development Platform. However,

this article

aims at two

important areas that only

.NET

was able to

manage appropriately. Those are:

• Creating intrinsically safe software architecture

• Managing multiple versions of Operating Systems, Software tools, and projects

Software Safety

Intrinsically Safe Software

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

but also and primarily by the system architecture, using voltages and currents which are "intrinsically safe" in the environment that the instrumentation will operate, so even in case of

a specific equipment failure, the system is protected.

When we started using the expression "intrinsically safe software", we got many questions

about its meaning for software

. It is

only to apply the same concepts we have in hardware to software systems,

namely that even

with a software component failure, the system architecture and design

have intrinsic protection for its safety and operation.

The previous generation of technology used C/C++, pointers, and several modules sharing the same memory area, direct access to hardware and to the operating system resources, and necessary procedures vis-à-vis computers and languages available at the time. However, we consider these to be intrinsically unsafe.

New Generation x Previous Generation

The new generation of software uses computational environments, such as the .NET Framework, where processes are natively isolated between themselves and the operating system regardless of the programmer, allowing better use of computers with multiple-processor cores and ensuring

higher operational stability, even in the face of potential drivers and hardware errors or failures on individual modules of the system

— this also applies to user scripting in applications

.

Previous generations used proprietary scripts or interpreted languages, such as JavaScript, VBScript, VBA, or proprietary expressions editors; the new generation relies on more modern and compiled languages such as C#, VB.NET, with control of exception

, multi-threading, enhanced security, and object-orientation and more execution control.

You cannot perform

full code validation during the development

phases with interpreted languages. The final validation is performed only when

the code

is

executed, which means that many problems are

tested only during the execution of the project, but not during the

technical configuration. A typical project may have hundreds to thousands of possible execution paths for the code, and the testing scenarios cannot test all

these paths by exhaustively running all

possible cases.

The ability to detect potential errors during the engineering and the ability to recover and isolate the errors during runtime are key elements for safety and operational stability, which are only possible by fully migrating the legacy interpreted scripts to the

newly compiled and managed languages.

Releases and Compatibility

High Availability

An

New releases and compatibility with previous applications

important question regarding high availability is how to manage the new release and system life-cycle management

.

In real

life, most

systems require updates, corrections, and enhancements after

their initial deployment; one of the most common factors that put the system's availability

at risk is exactly

change management. Even if the application itself

did not

change, it is necessary to install new computers, operating systems changes, and software tool updates

at some point.

When working

on the initial development of

our platform, we spent many months studying how to

manage

thit issue

better and how virtualized programming environments such as .NET and Java could help to achieve

this goal. In the end, we

discovered that when creating a system from the ground up, starting from a clean design, you can embed architectural components to help

managing future

releases.

System Availability

About the platform, .NET also showed a better platform over execution frameworks in this scenario

for a few reasons, including the support of multiple programming languages, easier integration with Microsoft server and client components,

more and faster graphical tools, high productivity development platform, among others.

Leveraging the .NET platform features, this article will explore three techniques used to ensure

maximum compatibility and system availability, even in case of new releases of .NET

or the application using classes or methods

deprecated in the new platform releases. Those 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 database, to store your application programming and configuration also helps

to keep backward compatibility when evolving the product. However,

we will focus on explaining the three items

connected most

with the 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 to create the application is

entirely in .NET Managed code.

For example

, we fully developed our version 2014.1

in C# code, .NET Framework 4.0. The first concept is using the software tool to create the final application projects, to expose most of the functionality not directly as a low-level platform call

but as an "Independent Application Layer". Let us explore and understand this concept.

Except for the Scripts created by the user that may include direct .NET calls — we will talk about user scripts in the next section —, the remainder of the software tool functionality, as much as possible, does not expose the .NET directly to the engineering user, presenting

a higher-level configuration tool instead.

Think about, for instance, displays, drawings, and animations in our platform. Instead of making the application engineers

go deep into .NET programming, it provides a higher-level interface

where you can enable the dynamic properties using dialogues

and deployment of those dynamic features internally in the system. Users do not have to interact with WPF, XAML, or .NET programming; they only use our high-level drawing and animation tools.

Thus, when an internal .NET Class is changed, the software can keep the same user

settings but internally implement the feature using the new .NET classes.

It allows us

to create a display drawing that will run natively in Microsoft .NET WPF and

Apple iOS Cocoa.

Example

Let us use the example of the "Bevel Bitmap effect"

deprecated in version 4.0.

Assume your application was using it.

According to this concept, instead of implementing the Bevel in user programming code, you would

have a "Configuration checkbox to enable Bevel dynamic" available in your "DYNAMICS" interface

— very similar to what we have as "SHINE- Outer Glow effect"

— so the user would select that animation to the object and the implementation would be done internally by the software configuration tool.

By removing that method from the .NET Framework, the package would replace the implementation

with another method or library to mimic that same visual effect to the user as much as possible,

 even though the internal

deployment is

totally different.

The same similar concept applies to other potential issues. Having an abstraction layer between your project development and the platform allows you to keep project compatibility and makes it possible to handle the necessary changes to make the project configuration compatible

with future .NET releases internally and transparently to the application engineers.

Multi-Targeting

Code Generation and Compiling Classes

Another great advantage of the

Built-in compiler supporting multi-targeting

.NET platform is its code generation and compiling classes, which allow you to embed a full .NET compiler within a Project Configuration tool. It allows the package to have complete control

over how we will parse and compile the scripts created by the users, even electing to compile the code to another version of the Microsoft .NET Framework.

By default, the system will compile the application scripts to the same .NET version the latest software tool is using

but

run them in their own AppDomain

. Also, we control the compiling, which means we can compile them, if necessary, to a previous .NET Framework version. 

Example

Let us explore a case scenario: imagine that you have a system created in Microsoft .NET version 4.0, and you have to migrate the system to a new .NET release 4.X. For this discussion, let us assume the application you created had scripts created using methods that were deprecated

in the

updated .NET Framework. What now?

There are two solutions for that:

• Solution A

• — If the deprecated method was replaced by another

• similar enough to be replaced automatically

• , the Project Configuration tool may have the Upgrade Utility to

• locate those methods in the code and replace them with the new one automatically. 

• Solution B

• — The project configuration tool can enable the users

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

• In the same way, Visual Studio can create DLLs to .NET 2.0, 3.5, 4.0, or 4.5, based on the user selection, and the embedded .NET compiler inside the Project Development tool

• can use similar features. Therefore, if necessary, we can enable your project

• to allow compiling the scripts in both

• too distinct .NET versions even if using the latest software configuration tool, according to the user selection of the TARGET.

• It is possible to have the same project running side-by-side with some script

• tasks under 4.0 and some

• script tasks 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 a different version of the .NET Framework running

concurrently.

Using

, for example, the core components we included

in our platform's project management and user-interface services, the system's different versions of the product can run

concurrently on the same computer. Furthermore, when running one project, the many modules, real-time database, scripts, and communication, do not run in the same Windows processes; they are isolated in their

process, exchanging data by a WCF (Windows Communication Foundation) connection.

In the same way, we have a

device communication

that creates

channel one Windows Process (one .NET AppDomain)

for each protocol that can also

apply to different user scripts in the project

— one can be compiled and running for .NET 4.0

; another one to other

releases. Both processes run side-by-side, with no conflict, each one in its

domain, both accessing the real-time tags on the server process.

32 and 64 bits

Another similar scenario is the feature that we have to manage 32 and 64 bits execution on the same project configuration.

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

run all its modules natively in

real 64-bit mode

when installing on 64 bits

operating systems.

However, sometimes, you

must force one specific script,

a communication driver, or even the graphics user Displays

to run in 32 bits

. 

For instance, you may be consuming an external code DLL or a graphical component from a third

party, which only works in 32 bits mode.

To accomplish that, we just provided

a RunModule32.exe version to allow one specific project component such as Scripts, Displays, or Device

Communication to run

a particular process in 32 bits, while the rest of the application is running 64 bits. The communication between those processes uses WCF, ensuring

total isolation among the processes.

Reliable Application

Creating a reliable application which are that is manageable on its life-cycle is of ultimate importance and one of the top benefits of using .NET and , instead of migrating previous code, creating new Software Tools from a the ground - up instead of migrating previous code, having a Project Configuration package that had its very first design with the goal to leverage the current currently available technologies.

Even though this new technology is available, many systems still relies in rely on code ported from DOS , or using Windows low-level APIs and previous versions that creates create the DLL-hell effect of Windows, where any update, any installation of another unrelated software, any change in any part of the system, could break it all.

Using the right features provided by .NET Framework, SQL databases, and adding on top of that a well-designed "Independent Application Layer", you can create systems that have high compatibility with previous applications , but not denying cannot deny the ability to keep truly evolving the feature set and the technology.

In this section...