Why is delivery over NuGet feed used for .NET Core?

Effective with version 2018.3, QuickOPC supports development for Microsoft .NET Core. QuickOPC libraries for .NET Core are only delivered through the public NuGet feed (http://www.nuget.org ). This is in contrast to the .NET Framework, where the developer can reference one or more QuickOPC .NET assemblies (there are only 5 or so of them at maximum) that are delivered in product's installation package (and the use of NuGet packages is simply a possible alternative for .NET Framework development). This article attempts to explain why NuGet is the only delivery vehicle for QuickOPC .libraries that target .NET Core.

TL;DR: NuGet feed is used because it is, in our understanding, the only approach that works well for the developer.

Introduction: How it works in .NET Framework

Let's explain the physical composition of QuickOPC when targeting the .NET Framework first. We will explain it on QuickOPC for OPC Unified Architecture, because it is the most relevant aspect needed for comparison with .NET Core. Your project developed with QuickOPC looks like this:

• You reference the OpcLabs.BaseLib and OpcLabs.EasyOpcUA assemblies from one or more of your project's assemblies.
• These two OpcLabs.* assemblies only reference assemblies that are part of the .NET Framework itself, and assemblies of OPC Foundation's UA .NET Stack which are embedded inside the OpcLabs.* assemblies (alternatively, they can be deployed alongside).
• The .NET Framework, with all its assemblies, is one monolithic piece, sitting pre-installed on the Windows computer (depending on the version, it either comes with the OS or is installed separately).

By shipping a handful of assemblies (in the above example, just OpcLabs.BaseLib and OpcLabs.EasyOpcUA), and instructing the user to have proper .NET Framework installed on the Windows computer, we basically have everything in place to run your project. The number of files we (and you) need to ship is small, stable, and completely predictable.