In or out? This is how you can find out whether your C# code would prefer to exist in its own application.

It’s always the same question: VSTA, ActiveX, .NET control or perhaps an EXE after all? So, we’d like to give you some new food for thought and criteria for making the best decision.

First things first: whether program code is best executed within the main application or as its own process depends very much on the particular case in question. There is no single rule for this. This blog post shows the differences, as well as advantages and disadvantages of both variants.

In principle, we distinguish between two types of code during considerations: code that is executed within the same process and that which is executed in a separate process.

The first type includes VSTA, ActiveX, .NET controls and all other variants whereby your code is loaded into the main application as DLLs. In this case, the main application and your code share the same virtual address space and use the same main thread. Mutual calls between your code and the main application are normal assembler calls, without overhead, so to speak.

If your code runs in a separate process, it has its own virtual address space and its own main thread completely to itself. It thus runs at the same time and completely disconnected from the main application – generally even on a different processor core. Mutual calls between this code and the main application do, of course, entail much more work, because it concerns a communication between two processes, the so-called interprocess communication. This means that each call beyond the process limits takes a relatively large amount of time. COM is generally used as the interface on Windows operating systems. The interprocess communication with COM works internally by sending Windows messages to hidden windows of the other application. A call can therefore even take up to a millisecond and is very dependent on system load. In principle, this speed disadvantage also applies to any other interface suitable for interprocess communication and is even more pronounced in most of them (sockets or pipes for example). A major advantage for the developer is that COM works exactly the same, regardless of whether it is used on an intraprocess or interprocess basis.

The zenon API

In the case of zenon, the complete zenon API is implemented as a COM interface. It can also be identically addressed by the same C# code – regardless of whether this runs within or outside of zenon Runtime. As a result, it is also not a problem if you only decide on the other variant later on.

In_and_Out_of_Process_Code_EN

In addition to the issue of how it works in runtime, there are other areas where differences occur. The following table provides an overview to help you in the decision-making process:

Tabelle_S25

Making a decision

If there is no knockout criterion in deciding for one or the other, we recommend comparing the number of mutual calls and the processing intensity of your code with one another. If many API calls and events are expected, internal code (such as VSTA) will be able to play on its performance strengths. If your code requires a lot of computing power, is memory-intensive and complex, but is rather loosely connected to the main application, then an external application has significant advantages when it comes to side effects, scalability and freedom of development. It is important in each new case that you ask yourself the question: in or out? Sometimes it can even make sense to execute a part of the code in zenon Runtime and another part as a separate process. There is no patented recipe for this, but zenon can competently support you with both variants.

Tags:

Leave a Reply