A2v10.CLI 10.1.8665

A2v10.CLI

Command-line tool for the A2v10 platform. It inspects an A2v10 project — its configuration, database, and endpoints — and returns everything as JSON.

Designed to be driven by an LLM coding assistant (Claude Code, Copilot, etc.): the output is machine-readable by default, every call is self-contained, and there are no interactive prompts. A human can run it just as well.

Install

It is a .NET global tool (requires the .NET SDK):

dotnet tool install --global A2v10.CLI

Update an existing install:

dotnet tool update --global A2v10.CLI

Verify:

a2 --version

Working directory

Run a2 from the application root — the project root, not WebApp, MainApp, or any module folder. The tool resolves configuration, modules, and the database connection relative to the current directory; from the wrong folder it will not work.

Configuration

a2 loads the same configuration as the running application, not a private one. From the application root it locates the host folder (WebApp/WebApiHost — the one with an appsettings.json) and reads:

{
  "ConnectionStrings": {
    "Default": "Server=.;Database=mydb;Trusted_Connection=True;"
  }
}

Then it layers User Secrets on top: it reads the UserSecretsId from the host's .csproj and loads that store (secrets.json, the same one Visual Studio and the running app use), so secrets override appsettings.json. This is deliberate:

• The whole secrets.json is loaded, not just the connection string — add a new service with a secret key to the app and the CLI sees it too, no changes here.
• The CLI has no secret store of its own; it always borrows the application's. There is no second, diverging configuration to maintain.

If the host .csproj has no UserSecretsId, only appsettings.json is used.

Output format

Every command returns JSON.

Success:

{ "success": true, "data": { ... } }

Error:

{ "success": false, "error": { "message": "..." } }

Table identifier format

schema.[Table] — used both as command arguments and in responses.

Examples: cat.[Agents], doc.[Invoice], cat.[Agent.Addresses].

Brackets are required — table names may contain dots.

Commands

a2 app config

Returns application-level configuration: multi-tenancy flag and the list of modules.

a2 app config

{
  "success": true,
  "data": {
    "multiTenant": false,
    "modules": [
      { "prefix": "$admin",    "root": null },
      { "prefix": "",          "root": "MainApp" },
      { "prefix": "$meta",     "root": null },
      { "prefix": "$workflow", "root": null }
    ]
  },
  "error": null
}

• multiTenant — whether the project is multi-tenant.
• modules — application modules. Each has a prefix (the literal URL token, including $; "" is the main app) and a root (the module's source folder from the project root, or null when the module has no local folder).

a2 db info

Shows which database the application is actually connected to — the target of every other a2 db command, and the database the user must apply generated SQL to.

a2 db info

{
  "success": true,
  "data": {
    "server": "localhost\\SQLEXPRESS",
    "database": "mydb",
    "source": "WebApp/appsettings.json",
    "exists": true,
    "platform": true
  }
}

• server, database — taken from the resolved connection string. The connection string itself is never printed: it may carry a password from user secrets.
• source — the configuration layer the connection string came from, i.e. the file to fix: a path from the project root, or user secrets (secrets.json).
• exists — whether that database exists on that server. false means the connection string names a database the server does not have. A server that cannot be reached at all is a different thing: the command fails (success: false).
• platform — the database carries the A2v10 schema (a2security.[Users] is present). false on an existing database means it is some other database, not an A2v10 one.

System-database guard. If Database= resolves to master, model, msdb or tempdb, every a2 db command fails with

The connection string points to the system database [master]. Fix `Database=` in WebApp/appsettings.json.

The guard is on all db commands, not just info: pointed at master, a2 db tables would otherwise return an empty list — a confident, silent, wrong answer.

a2 db tables [schema]

Lists database tables, grouped by schema. Optional schema filters by schema name.

a2 db tables
a2 db tables cat

{
  "success": true,
  "data": ["cat.[Agents]", "cat.[Units]", "cat.[Currencies]", "doc.[Invoice]"]
}

a2 db table-columns <table>

Returns the structure of a table. Conventions: Id is always the primary key, FK columns are nullable.

a2 db table-columns cat.[Agents]

{
  "success": true,
  "data": {
    "columns": [
      { "name": "Id",     "type": "bigint" },
      { "name": "Name",   "type": "nvarchar(255)" },
      { "name": "Code",   "type": "nvarchar(16)" },
      { "name": "Agent",  "type": "bigint", "ref": "cat.[Agents]" },
      { "name": "Parent", "type": "bigint", "ref": "cat.[Agents]", "identity": true }
    ]
  }
}

• ref — reference to another table, in canonical format.
• identity: true — auto-increment column.

a2 db referenced-by <table>

Lists tables and columns that reference the given table.

a2 db referenced-by cat.[Agents]

{
  "success": true,
  "data": [
    { "table": "doc.[Invoice]",  "column": "Agent" },
    { "table": "doc.[Order]",    "column": "Agent" },
    { "table": "cat.[Contacts]", "column": "PrimaryAgent" }
  ]
}

a2 endpoint resolve-* <route>

Resolves a single model.json element the way the runtime sees it: the view/template files it is bound to, the SQL procedures it calls, and the data-model type tree it returns. Useful for verifying that the layers (model.json, XAML, SQL) agree after a deploy.

route addresses the element as /[$<module>]/<path>/<element>, e.g. catalog/agent/edit. No record id is needed — types come from the result-set schema.

One command per model.json section:

The three renderable commands share one output shape:

a2 endpoint resolve-action catalog/agent/edit

{
  "success": true,
  "data": {
    "route": "catalog/agent/edit",
    "model": "Agent",
    "view":     { "route": "catalog/agent/edit", "file": "view.dialog.vxaml" },
    "template": { "route": "catalog/agent/edit", "file": "edit.template.ts" },
    "sqlProcedures": {
      "load":   "cat.[Agent.Load]",
      "update": "cat.[Agent.Update]"
    },
    "dataModel": {
      "types": {
        "TRoot":  { "props": { "Agent": { "type": "TAgent", "len": null } }, "id": null, "name": null },
        "TAgent": { "props": { "Id":   { "type": "number", "len": null },
                               "Name": { "type": "string", "len": 100 } }, "id": "Id", "name": "Name" }
      }
    }
  },
  "error": null
}

A resolve-command for the commands section (callables — view/template absent, sqlProcedures = what the command calls) is planned, not yet implemented. Until it ships, read a command's procedure binding directly from the commands section of model.json.

These commands require the project to be deployed (migrations applied, build done). Run before deployment, they fail by design.

License

See the package license.