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 brought introduced higher and unique features to create for creating high-availability systems.

.NET features regarding , including productivity tools, development helpaids, class libraries, and communication standards with , play a crucial role in improving a Project Development Platform. However, this article aims at focuses on two important areas that only .NET was able to manage appropriately. Those aremanages 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' warranty warranties but also and primarily by the system architecture, using which uses voltages and currents which that are "intrinsically safe" in the environment that where the instrumentation will operate, so . This ensures that even in case the event of a specific equipment failure, the system is remains protected.

When we started began using the expression term "intrinsically safe software," , we got received many questions about its meaning for in the context of software. It is only refers to apply applying the same concepts we have in hardware to software systems. Specifically, namely that even with if a software component failurefails, the system architecture and design should have intrinsic protection for its to ensure safety and operationoperational integrity.

The previous generation of technology used relied on C/C++, pointers, and several modules sharing the same memory area, with direct access to hardware and to the operating system resources. These methods, and necessary procedures vis-à-vis computers and languages available while necessary at the time. However, we consider these to be intrinsically unsafe, are considered intrinsically unsafe by today's standards.

New Generation x Previous Generation

The new generation of software uses utilizes computational environments , such as the .NET Framework, where processes are natively isolated between themselves from each other and the operating system, regardless of the programmer, allowing better use . This approach allows for better utilization of computers with multiple - processor cores and ensuring ensures higher operational stability, even in the face of potential drivers driver and hardware errors or failures on in individual modules of the system — this system modules. This also applies to user scripting in within applications.

Previous generations used relied on proprietary scripts or interpreted languages, such as JavaScript, VBScript, VBA, or proprietary expressions expression editors; the . The new generation relies on more leverages modern and , compiled languages such as like C# , and VB.NET, with offering control of exceptionover exceptions, multi-threading, enhanced security, and object - orientation, and more better execution control.

You cannot perform Interpreted languages do not allow for full code validation during the development phases with interpreted languages. The final validation is performed . Validation occurs only when the code is executed, which means that meaning many problems issues are tested discovered only during the project execution of the project, but not during the technical configuration. A typical project may have hundreds to thousands of possible potential execution paths for the code, and the exhaustive testing scenarios cannot test of all these paths by exhaustively running all possible casesis not feasible.

The ability to detect potential errors during the engineering and the ability to recover and isolate the errors during runtime are key elements critical for safety and operational stability, which are only possible by fully migrating the . This level of assurance is achievable only by migrating legacy interpreted scripts to the newly newer compiled and managed languages.

Releases and Compatibility

High Availability

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

In real lifepractice, most systems require updates, corrections, and enhancements after their initial deployment; one . One of the most common factors that put the jeopardize a system's availability at risk is exactly change management. Even if the application itself did not change, it is necessary to install remains unchanged, installing new computers, updating operating systems changes, and applying software tool updates at some pointcan affect system stability.

When working on During the initial development of our platform, we spent many months studying how to better manage thit this issue better and how virtualized programming environments such as like .NET and Java could help to achieve assist in achieving this goal. In the endUltimately, we discovered that when creating a system from the ground up, starting from a clean design , you can embed allows for embedding architectural components to help managing future releasesthat facilitate future releases and updates, thus improving the management of system changes and maintaining high availability.

System Availability

About the platform, .NET also showed a better platform over execution frameworks in this scenario for a few has proven to be a superior execution framework for several reasons, including the its support of for multiple programming languages, easier integration with Microsoft server and client components, more and faster graphical tools, and a high productivity development platform, among others.

Leveraging the features of the .NET platform features, this article will explore three techniques used to ensure maximum compatibility and system availability, even in case the event of new releases of .NET or the application applications using deprecated classes or methods deprecated in the new platform releases. Those . 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 databasedatabases, to store your application programming and configuration also helps to keep maintain backward compatibility when evolving as the product evolves. However, we this article will focus on explaining the three items connected most with the 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 software tool used to create the application is entirely in .NET Managed managed code. For exampleinstance, we fully developed our version 2014.1 was fully developed in C# code, using .NET Framework 4.0. The first concept is involves using the software tool to create the final application projects, to expose exposing most of the functionality not directly as a low-level platform call calls but as an "Independent Application Layer." . Let us explore and understand this concept.

Except for the Scripts created by the user scripts that may include direct .NET calls — we will talk about user scripts calls—discussed in the next section —, the section—the remainder of the software tool functionality, as much as possible, does not expose the tool’s functionality is designed to avoid exposing .NET directly to the engineering user. Instead, presenting it presents a higher-level configuration tool instead.

Think about, for instance, Consider displays, drawings, and animations in our platform. Instead of making the requiring application engineers go deep to delve into .NET programming, it the platform provides a higher-level interface where you can enable the for enabling dynamic properties using through dialogues and internal deployment of those dynamic features internally in the system. Users do not have to interact with high-level drawing and animation tools rather than dealing with WPF, XAML, or .NET programming; they only use our high-level drawing and animation tools.

Thus, when an internal .NET Class class is changed, the software can keep maintain the same user settings but internally implement the feature using the new .NET classes. It This approach allows us to create a display drawing drawings that will run natively in 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 itthis effect.

According to this the concept, instead of 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 — very similar to what we have as interface—similar to the "SHINE - Outer Glow effect." — so the The user would select that this animation to the for an object, and the implementation would be done handled internally by the software configuration tool.

By removing that method When the Bevel method is removed from the .NET Framework, the software package would replace the deprecated implementation with another method or library to mimic that mimics the same visual effect to the user as much closely as possible,  even even though the internal deployment is totally differentdiffers.

This approach ensures that the user experience remains consistent, despite changes in the underlying technology. The same similar concept applies to other potential issues. Having By having an abstraction layer between your project development and the platform allows , you to keep can maintain project compatibility and manage necessary changes internally. This makes it possible to handle keep the necessary changes to make the project configuration compatible with future .NET releases internally and transparently to the in a way that is transparent to application engineers. Anchor_GoBack_GoBack

Multi-Targeting

Code Generation and Compiling Classes

Another great significant advantage of the .NET platform is its support for code generation and compiling classes, which allow you to embed allows embedding a full .NET compiler within a Project Configuration tool. It allows the package to have This capability provides complete control over how we will parse and compile the scripts created by the users, even electing the system parses and compiles user-created scripts, including the option to compile the code to another version for different versions of the Microsoft .NET Framework.

By default, the system will compile the application scripts to match the same .NET version used by the latest software tool is using but run them in , running them within their own AppDomain. AlsoAdditionally, we this control the compiling, which means we can compile them, if necessary, to a previous allows the system to compile scripts to an earlier .NET Framework version if necessary. 

Operating System Independency

when using  the  With .NET 8, you can also have run the exact same code running on Linux, macOS, MacOS or 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 have need 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 thatthis:

• Solution A — If the deprecated method was replaced by another similar enough to be replaced automatically, the Project Configuration tool may have the an Upgrade Utility to locate those methods in the code and replace them with the new one ones automatically. 

• Solution B — The project configuration tool can enable the allow users to select the .NET TARGET of the project scripts. In the same way, Just as Visual Studio can create DLLs to for .NET 2.0, 3.5, 4.0, or 4.5 , based on the user selection, and the embedded .NET compiler inside within the Project Development tool can use similar features. Therefore, if necessary, we can enable your project to allow compiling compile the scripts in both too distinct .NET versions, even if 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 some script tasks 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 a different version versions of the .NET Framework FrameworX 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 various modules, real-time database, scripts, and communication , components do not run in the same Windows processes; they are isolated in their processown processes, exchanging data by via a WCF (Windows Communication Foundation) connection.

In the same way, we have a Similarly, device communication that creates channel one a separate Windows Process (one .NET AppDomain) for each protocol that , which can also apply to different user scripts in the project — one can be project—one compiled and running for .NET 4.0; , and another one to for other releases. Both processes run side-by-side, with no conflict, each one in its own domain, and both accessing the real-time tags on the server process.

32 and 64 bits

Another similar scenario is the feature that we have allows us to manage 32-bit and 64 bits -bit execution on within 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 installed on 64 bits -bit operating systems.

However, sometimes , you must may need to force one a specific script, a communication driver, or even the graphics graphical user Displays displays to run in 32 bits-bit mode. 

For instance, if you may be consuming are using an external code DLL or a graphical component from a third party , which that only works in 32 bits mode. To accomplish that-bit mode, we just provided provide a RunModule32.exe version to allow one that specific project component such component—such as Scriptsscripts, Displaysdisplays, or Device Communication to device communication—to run in a particular process in 32 bits32-bit process, while the rest of the application is running 64 bitsruns in 64-bit mode. The communication between those these processes uses WCF, ensuring total 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...