.NET quickstart

This page gets the Monaiq .NET client installed, configured and registered in a .NET application, and shows you where the licensing calls come from afterwards.

The package is Sidub.Licensing.Client, and it targets netstandard2.1.

Install

dotnet add package Sidub.Licensing.Client

Configure and register

The client is configured through LicensingServiceOptions and registered with AddSidubLicensing(). In a minimal hosting Program.cs:

var builder = WebApplication.CreateBuilder(args);

builder.Services.Configure<LicensingServiceOptions>(options =>
{
    options.LicenseServiceUri = "https://api.monaiq.com/licensing";
    options.ConsumptionServiceUri = "https://api.monaiq.com/consumption";
    options.EncodedCredential = builder.Configuration["Licensing:EncodedCredential"];
});
builder.Services.AddSidubLicensing();

var app = builder.Build();

That is the whole setup: AddSidubLicensing() registers everything the SDK needs, including the service connectors built from the options above — there is no separate registration step. If an option is wrong, the application fails at startup with a message naming the option (LicenseServiceUri must be an absolute URI, for example) rather than failing on the first licensing call.

Three things are being set:

• LicenseServiceUri is the licensing API, which answers the authorization and feature questions.
• ConsumptionServiceUri is the consumption API, which handles metered usage. Consumption and metering covers when you need it.
• EncodedCredential is your credential, read from configuration rather than written into the file.

Both addresses are the production ones and are listed in Endpoints.

Supplying the credential

EncodedCredential takes the portable credential string that starts SIDUB_LIC_. The example reads it from the configuration key Licensing:EncodedCredential, which in appsettings.json looks like this:

{
  "Licensing": {
    "EncodedCredential": "SIDUB_LIC_..."
  }
}

Caution

The credential is a secret. Keep the real value out of source control: put it in user secrets while you develop and in your host’s configuration or secret store in production, and let the same configuration key read it in both places.

The string carries a token minted for one seat, so it authorizes and meters that seat and reaches nothing else. Do not decode it and do not read the token inside it — configure it and the SDK calls the runtime operations with it. The two service URIs above stay exactly as they are: the SDK appends /runtime itself.

Where the value comes from, how to issue another and how to revoke one, is in Credentials and keys.

Calling the service

AddSidubLicensing() registers ILicensingService, which you take from dependency injection wherever you need to make a licensing decision. Its members are:

• GetAuthorization for the current authorization, which is the starting point for everything else.
• GetLicenseFeature<T> for a single feature of the license. It returns null when the license does not carry the feature — treat that as “not licensed”, don’t suppress it.
• PerformOperation<TFeature, TState> for work that runs against a feature.
• AssertLicense for enforcing a condition rather than inspecting one.
• GetLicenseFeatureState<TFeature, TState> and SetLicenseFeatureState<TFeature, TState> for reading and writing a feature’s local state — a rate-limited feature’s consumption, for example.

Two supporting types come with it: LicensingContextAccessor for the current licensing context, and LicensingServiceReference for identifying the service itself. .NET client reference lists the full surface.

When an API call fails, the SDK throws LicensingApiException carrying the server’s error contract — the machine-readable Code to branch on, and the CorrelationId to quote when contacting support. The .NET client reference describes the fields.

Selling from inside your app

The same package carries IPurchaseClient, for an application you distribute that sells your offerings from inside itself. It is registered separately, with AddSidubLicensingPurchaseClient, and it holds no key of yours: the buyer signs in with their Monaiq identity and buys with their own token, the app reads your catalog anonymously, and the credential that comes back is what EncodedCredential above takes. In-app purchase covers the flow, the sign-in choice and the client.

Getting the calls written for you

If you would rather not work out the call sites by hand, the AI-assisted path does exactly that: its implement_base and implement_product_feature tools return the wiring and the feature check for your own project, and provision_api_key_config returns the commands and file edits that plumb the credential in. See AI-assisted setup.

Next

• Credentials and keys for minting and rotating what you configured above.
• Consumption and metering if your offering meters usage.
• In-app purchase if the application you ship should sell as well as enforce.