In This Topic

At the core of QuickOPC.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.

For easy recognition among other assemblies when used in a larger context, all our assemblies start with “OpcLabs” prefix.

Assembly List

Following assemblies form the main part of QuickOPC.NET:

Assembly Name or File	Title	Description	Strong-named	Present locally - for .NET Framework	Present in NuGet package - .NET Framework	Present in NuGet package - .NET Standard
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 Core	Supporting code.	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.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	✓	✓	✓

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

When targeting .NET Framework, the OPC Unified Architecture components are based on version 1.03 of the .NET Stack from OPC Foundation. When targeting .NET Standard, the OPC Unified Architecture components are based on version 1.04 of the .NET Stack from OPC Foundation.

For the curious, QuickOPC has been developed in Microsoft Visual Studio 2019. 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#.

Additional packages

QuickOPC also includes packages (sets of assemblies) that are only used in specific circumstances, as documented. They are available as NuGet packages (from www.nuget.org , for use in .NET Standard projects), or as ZIP packages (links to corresponding ZIP file downloads are installed with the product and reachable through Redistributables item in the Start menu or the Launcher program).

The additional packages include e.g.:

The additional packages may have their own licensing requirements, different from the core QuickOPC.

Assemblies for .NET Framework

The assembly files are installed into a subdirectory called Assemblies\net47 under the installation directory of the product.

QuickOPC components were consciously written to target Microsoft .NET Framework 4.7, 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, 4.7.1, 4.7.2 or 4.8 of the Microsoft .NET Framework.

There is also a Design subfolder under the Assemblies folder, which contains additional QuickOPC assemblies that are used during design time only. These assemblies are never referenced or used in run-time by your projects.

For development purposes, the assemblies under the Design subfolder are installed into the GAC (Global Assembly Cache) by the setup program. Other (runtime) assemblies are not installed into the GAC by default (the installation program can do it if you select the custom installation, it will then offer you this option near the end of the installation). You do not have to install assemblies into the GAC on the runtime computers, though. We recommend against installing the runtime assemblies into the GAC, unless you have a compelling reason for it.

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 assemblies are also necessary when you are using COM components for OPC. They are implemented in .NET, and exposed to the COM worlds using a COM interop.

Assemblies for .NET Framework are also used when you target the Excel as a development platform, with Excel Option.

Assemblies for .NET Standard

In .NET Standard, the QuickOPC 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 QuickOPC 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 QuickOPC NuGet package(s) into your project, it ends up referencing more (possibly many) assemblies than explicitly listed here.

Strong-naming

As a general rule, QuickOPC 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 QuickOPC 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 QuickOPC 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.

Also, assemblies that are not strong-signed cannot be put to GAC (Global Assembly Cache).