At the core of OPC Data Client.NET, there are .NET assemblies that contain reusable library code.  You reference these assemblies from the code of your application, and by instantiating objects from those assemblies and calling methods on them, you gain the OPC functionality.

Application programming interfaces (APIs) for other COM and Python are built on top of .NET assemblies. For this reason, when you work with OPC Data Client, you will end up using the .NET assemblies described here in all cases, although indirectly.

For easy recognition among other assemblies when used in a larger context, all our assemblies (with 2 exceptions noticeable below) start with “OpcLabs” prefix.

Assembly List

Following assemblies form the main part of OPC Data Client.NET:

Assembly Name or File	Title	Description	Strong-named	Present for .NET Framework	Present for .NET 6+
App_Web_OpcLabs.EasyOpcClassicRaw.amd64	EasyOPC “Classic” Raw Library	Used internally. Low-level OPC “Classic” code, a mixed mode assembly, for 64-bit processes (x64 architecture).	yes	✓	⨯
App_Web_OpcLabs.EasyOpcClassicRaw.x86	EasyOPC “Classic” Raw Library	Used internally. Low-level OPC “Classic” code, a mixed mode assembly, for 32-bit processes (x86 architecture).	yes	✓	⨯
OpcLabs.BaseLib	OPC Labs Base Library	Supporting code.	yes	✓	✓
OpcLabs.BaseLibComponents	OPC Labs Base Library Components	Top-level non-visual supporting components.	yes	✓	✓
OpcLabs.BaseLibForms	OPC Labs Base Library Forms	Contains fundamental and common classes for Windows Forms.	yes	✓	✓
OpcLabs.BaseLibPresentation	OPC Labs Base Library Presentation	Contains fundamental and common classes for Windows Presentation Foundation (WPF).	yes	✓	⨯
OpcLabs.DotProlog	OPC Labs DotProlog	Used by OpcLabs.BaseLibForms.	yes	✓	✓
OpcLabs.EasyOpcClassic	EasyOPC “Classic” Library	Contains classes that facilitate easy work with various OPC specifications, such as OPC Data Access, OPC XML-DA, and OPC Alarms and Events.	yes	✓	✓
OpcLabs.EasyOpcClassicComponents	EasyOPC “Classic” Components Library	Top-level non-visual OPC "Classic" components.	yes	✓	✓
OpcLabs.EasyOpcClassicCore	EasyOPC “Classic” Core Library	Contains classes that facilitate easy work with various OPC specifications, such as OPC Data Access, OPC XML-DA, and OPC Alarms and Events.	yes	✓	✓
OpcLabs.EasyOpcForms	EasyOPC Forms	Contains classes that facilitate easy work with OPC (both “Classic” and Unified Architecture) from Windows Forms applications.	yes	✓	✓
OpcLabs.EasyOpcPresentation	EasyOPC Presentation	Contains classes that facilitate easy work with OPC (both “Classic” and Unified Architecture) from Windows Presentation Foundation (WPF) applications.	yes	✓	⨯
OpcLabs.EasyOpcUA	EasyOPC-UA Library	Contains classes that facilitate easy work with OPC Unified Architecture.	yes	✓	✓
OpcLabs.EasyOpcUAComponents	EasyOPC-UA Components Library	Top-level non-visual OPC UA components.	yes	✓	✓

The name of the physical file that contains the assembly is always same as the name of the assembly, with a file extension “.dll”.

The OPC Unified Architecture components are based on version 1.04 of the OPC UA .NET 6+ Stack from OPC Foundation (no matter whether you are targeting .NET Framework or .NET 6+).

For the curious, OPC Data Client has been developed in Microsoft Visual Studio 2022. The layers that directly use COM (such as the OpcLabs.EasyOpcClassic assembly) are written in managed C++ (C++/CLI). More precisely, they are mixed mode assemblies, where the bulk of the code is in MSIL instructions, with a few exceptions where necessary. All other parts are written in pure C#.

Assemblies for .NET Framework

For .NET Framework, the OPC Data Client assemblies are provided in form of NuGet Packages, available from www.nuget.org. Such assemblies do not have a fixed or "well-known" installation location on your computer, and are installed separately into each project that uses them.

In addition, the OPC Data Client NuGet packages have dependencies on other NuGet packages, and so on. The precise structure and content of these dependencies depends on the targeted runtime. Consequently, by installing the OPC Data Client NuGet package(s) into your project, it ends up referencing more (possibly many) assemblies than explicitly listed here.

OPC Data Client components were consciously written to target Microsoft .NET Framework 4.7.2, i.e. they do not depend on features available only in the later version of the framework. As such, you can use the components in applications targeting version 4.7.2 or 4.8 of the Microsoft .NET Framework.

The somewhat strange naming of certain assemblies, with names starting with “App_Web_” prefix, is needed for proper mixed-mode assembly loading under ASP.NET. Do not be confused by the presence of the word “Web” in the name – the same assemblies are needed outside of Web applications as well.

The .NET Framework assemblies are also necessary when you are using COM components for OPC. The OPC Data Client COM components are implemented in .NET Framework, and are exposed to the COM worlds using a COM interop.

Assembly files built for .NET Framework are also used when you target the Excel as a development platform, with Excel Connector, or when using OPC Data Client from PowerShell.

For the above mentioned purposes, besides being available in NuGet Packages, the assembly files for .NET Framework are installed into a subdirectory called Components\Opclabs.QuickOpc\net472 under the installation directory of the product.

Assemblies for .NET 6+

In .NET 6+, the OPC Data Client assemblies are not installed using a Setup Program. Instead, they are provided in form of NuGet Packages, available from www.nuget.org. The assemblies do not have a fixed or "well-known" installation location on your computer, and are installed separately into each project that uses them.

In addition, the OPC Data Client NuGet packages have dependencies on other NuGet packages, and so on. The precise structure and content of these dependencies depends on the targeted runtime. Consequently, by installing the OPC Data Client NuGet package(s) into your project, it ends up referencing more (possibly many) assemblies than explicitly listed here.

Strong-naming

As a general rule, OPC Data Client assemblies are strong-named.

An exception to this rule is made when we need to reference other assemblies that are not strong-named. In such case, we move such parts into a separate OPC Data Client assembly that is not strong-named. Usage of these parts is always optional and depends on the functionality you need. An example of this approach is the OpcLabs.Pcap assembly, which references the SharpPcap and PacketDotNet assemblies. You only need it when your application uses OPC UA PubSub Ethernet mapping, or when it works with Wireshark capture files.

The OPC Data Client assemblies that are strong-signed cannot directly reference the assemblies that are not strong-signed. For this reason, the assemblies that are strong-signed load the assemblies that are not strong-signed dynamically. Consequently, different (and platform-dependent) rules apply to where such assemblies are being searched for.