If you plan to support only MS Windows and the target is a PC with lots of RAM, .NET is fine. Especially if you only have .NET experts and no C++ developers, .NET it the correct choice for you.
Keep in mind: The resulting application will not be as high-performing as the C++ alternative and will consume much more resources. If you should later decide that your product should also support other operating systems or embedded devices, you cannot reuse any of your .NET code. You’ll have to reprogram your code starting from zero. A decision for .NET is decision to be bound to MS Windows. The .NET SDK requires at least .Net 3.5 SP1. It does not work with older versions, neither with .NET Compact Framework nor .NET Mono. Windows and .NET currently only work on x86 (and x86-64) architectures.
If you plan to support multiple operating systems, or if you need maximum performance, the C++ SDK is the correct choice. Especially if you have C++ developers, it makes no sense to choose another technology like .NET or Java, because C++ developers are faster in developing C++ than with other technologies. (Rapid application development is a matter of good libraries, not a matter of the programming language.) The C++ SDK works multi-threaded to benefit from modern multi-core CPUs and can be compiled for 32bit and 64bit CPUs. The code is known to work on x86 and ARM and can easily ported to other architectures.
Keep in mind: Even if you plan to support only one operating system like Windows at the moment, it’s no problem to support other operating systems later on. The only limitation is the requirement of a C++ compiler. Some embedded systems may not allow multi-threading or even may not have a C++ compiler. In this case the only solution is to use the ANSI C SDK.
If you plan to support embedded devices or just want to use the most portable code, you should use the ANSI C SDK. The ANSI C SDK works asynchronously and single-threaded. Therefore no multi-threading is needed. ANSI C compilers are available for almost all operating systems and CPU architectures. The ANSI C version is proven to work on x86, ARM, MIPS using Linux, vxWorks, QNX, Euros, WinCE, Windows XP. Actively supported by Unified Automation are Linux and Windows on x86. Other ports can be obtained by our development partner ascolab GmbH.
Keep in mind: The ANSI C SDK has the fewest requirements in code size, RAM size and CPU power. But it cannot directly benefit from multi-core CPUs like new ARM CPUs, because it only uses one task/thread. This is often no disadvantage, but a desired feature. Especially on embedded systems, where OPC UA communication is just a small part of a bigger application. However a device could use one CPU core explicitly for the main task (e.g. a PLC program), and the second core can be use by another task like the OPC UA server.
If you plan to support multiple platforms, including "native" Android development, JAVA is a good choice. You can certainly develop faster, or more comfortable with JAVA and .NET, which known as more higher level environmants compared to C and C++. However, you need to keep the resource requirements for memory and CPU power in mind. The main advantage is that you don’t need to recompile your application for each platform. The JAVA program will run on each platform that brings the required JRE (JAVA Runtime Environment) the application was build for. We offer the Java SDK from our development partner ProsysOPC.