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.

The .NET Core is different

.NET Core uses NuGet packages as its primary referencing mechanism for itself and all the software that builds upon it, so would almost dismiss the question by saying the using it *is* the way to do things. But there are good reasons for using NuGet on our side as well - in fact, it would be difficult to do it in any other way. With .NET Core, you are entering a landscape that is much more modularized, more diverse, and also dynamic. More modularized: .NET Core does not come in one piece, but in many separate modules that are referenced separately. More diverse: Because it does not run only on Windows, but also on Linux, and other systems - and different distributions of them too. In addition, the modules and their composition and mutual references differ depending on the target system! Dynamic: The referencing mechanism does not necessarily require that precise versions of certain packages and assemblies are always used; for example, newer version of a package can be pulled in if available, and the referencing package allows it.

Let's try to build a QuickOPC project for .NET Core that is equivalent to the .NET Framework project described above, and doing it the same way - by referencing specific assemblies and trying to ship them with the product: