The NuGet catalog belongs to the Application, the same as every other artifact it owns. Every pipeline component and every custom function resolves its using statements against the catalog of the Application it lives in, and against no other. There is no shared workspace catalog: if two Applications need the same library, each registers it. Within an Application there is no rebuild step when a new consumer picks up a package that is already registered.

The catalog view follows the platform's Selected Application behavior, with an Application selected, the list filters to it and the Application column is hidden; with no selection, the list spans every Application you have access to and the column is shown. Adding a package uses the same flow: with an Application selected, the form opens with that Application preemptively chosen; without one, the form exposes an Application picker. Registrations are managed by the Application Owner and the Application Contributor, the same permission that governs every other artifact in the Application, no system-level role is involved.

Packages are added from the NuGet catalog screen in the Art2link ESB UI, into the catalog of one Application. Each entry has a name and a version, both required, both verbatim as published on the feed.

Packages come from public nuget.org and nowhere else. There is no feed setting, and private or authenticated NuGet feeds are not supported. If a library is not published on nuget.org, it cannot be registered in an Application's catalog. Because there is no feed to authenticate against, a registration carries no credential of any kind.

Once saved, the package is available to every pipeline component and custom function in that Application, and to no consumer outside it. There is no compile step at the catalog level; the package becomes usable the moment a consumer saves code that references it.

From a pipeline component or a custom function, reference the package with a standard using statement at the top of the code, then call into its API the way any .NET project would. The platform resolves the using against the catalog of the consumer's own Application when the component or function is saved.

using CC.Art2link.Attributes;
using System.Data;
using Microsoft.Data.SqlClient;   // resolved against the NuGet catalog

namespace Custom.Functions;

public static class DatabaseLookup
{
    [CustomFunction("fnLookupCustomerName")]
    public static string LookupCustomerName(string id, string connStr)
    {
        using var conn = new SqlConnection(connStr);
        conn.Open();
        // …
    }
}

The platform records the association from the consumer (this custom function, by name) back to the catalog entry (Microsoft.Data.SqlClient at the version this Application has registered). The association is what powers the impact-analysis view below.

Inside a single Application the same package can be registered at more than one version. Each version is a separate catalog entry, and each consumer is bound to one specific entry. A custom function that needs Microsoft.Data.SqlClient 5.1.5 and a pipeline component in the same Application that needs 6.0.2 can coexist without forcing the other to move.

Every time a pipeline component or custom function is saved with a using that resolves to a catalog entry, the platform records the association: this consumer references this package at this version. The catalog list shows package + version on the left; selecting a row opens a detail panel that lists every consumer associated with that exact entry. Every consumer on that list belongs to the same Application as the entry, so the list is also the whole blast radius.

The list is what makes a version bump or removal a deliberate decision rather than a guess. Before changing or removing a catalog entry, every consumer of that exact version is named, the pipeline components by name, the custom functions by name. Anything that breaks is in this list, and because the entry is owned by one Application, nothing outside that Application is in scope.

The catalog supports the same two safe-to-do moves any package manager does, bumping a version and removing an entry, with the consumer list as the safety net. The recommended order is impact-first: look at who is bound to the entry before you touch it.