Build C# / .NET Apps on Your Business Data with the New CData CLI


The CData CLI is a command-line tool that lets AI coding agents like Claude Code, Cursor, GitHub Copilot, and Gemini CLI reach your business data through CData drivers. Salesforce, NetSuite, Jira, Snowflake, SAP, and hundreds of other SaaS and database sources become queryable right from your terminal.

This article focuses on using the CLI for building C# / .NET applications. AI coding agents are great at writing C#, but they stumble the moment that code has to talk to a real system. The problem isn't code generation; it's that the agent has no grounded picture of your data. The CData CLI fixes that.

The architecture: one data model, many drivers

CData drivers (JDBC, ADO.NET, ODBC, and the Python Connector) expose the same relational model over the same SQL dialect. The edition you use changes how your program links to the driver, but the tables, columns, and SQL do not.

  • cdatacli is a Java tool that runs on the JDBC driver (requires Java 17+). Through it you create a connection, list tables and columns, and run real SQL against the live source.
  • Because the model is shared, anything you validate through the CLI transfers verbatim to whatever edition your app uses. The SELECT ... FROM Opportunity you confirm at the command line is the same statement your .NET app runs through the ADO.NET Data Provider.

Two-phase workflow:

Discovery  ──►  cdatacli  (JDBC)          → connect, list tables/columns, validate SQL
                    │
                    ▼  (same data model + SQL)
Build      ──►  CData ADO.NET Data Provider → write the .NET app

From workflow to skill

Skills are instruction files an AI coding tool loads on demand:

  • cdata-cli: the discovery skill. Connect to a source, explore schema, validate SQL, download and activate JDBC drivers.
  • cdata-cli-adonet: the .NET build skill. Takes over once discovery is done and you're ready to write C#.

cdata-cli is language-agnostic and is where the grounding happens. The build skill focuses on the parts specific to the ADO.NET provider: how to get it and how to connect.

What the .NET skill handles

npx skills add CDataSoftware/cli-skills --skill cdata-cli-adonet

cdata-cli-adonet encodes the non-obvious specifics of the ADO.NET Data Provider:

  • Language to edition mapping. C# (also VB.NET, F#) uses the CData ADO.NET Data Provider, in the System.Data.CData.<Source> namespace with standard ADO.NET types (<Source>Connection, <Source>Command, <Source>DataAdapter).
  • Getting the provider. It's a NuGet package, CData.<Source>, added with dotnet add package CData.<Source>. This is a distinct step from the CLI: cdatacli downloads JDBC jars only, so the ADO.NET provider comes from NuGet separately. Use the plain package, not the EntityFrameworkCore variants.
  • Licensing is separate and per-machine. A working cdatacli connection proves the JDBC edition is licensed, not the ADO.NET provider. The .NET Framework (net40) build self-licenses on NuGet restore; the .NET Core / .NET (netstandard2.0) build must be activated once with the install-license tool in the package's tools/ folder.

The net effect: the agent adds the right package, activates it, and writes correct ADO.NET code on the first try, reusing the SQL it already validated.

Example: building a real .NET app

Prompt given to an AI coding agent with both skills installed:

"using /cdata-cli build a c# TUI that shows the open tasks in my active projects in asana."

The agent handled it in two phases: discovery with cdata-cli, then build with cdata-cli-adonet. Project, task, and assignee names below are redacted and generalized.

Step 1: Discovery — get the driver (via the CLI, on JDBC)

The Asana driver wasn't installed yet, so the agent had the CLI fetch and activate it, then confirmed the connection with a live count: 

cdatacli drivers download --artifact-id asana-jdbc
cdatacli drivers activate Asana --name "First Last" --email "[email protected]" --trial
cdatacli query sql --connection asana --sql "SELECT COUNT(*) AS c FROM Projects"
{ "resultset": [ { "c": 103 } ] }

Step 2: Discovery — explore the schema and validate the query

The agent inspected the Projects and Tasks columns, then ran the actual queries the app would use against live Asana. Two schema facts emerged: Tasks must be filtered by ProjectId (Asana returns tasks per project), and Tasks.Completed separates open from done: 

cdatacli query sql --connection asana --sql "SELECT Id, Name FROM Projects WHERE Archived = false ORDER BY ModifiedAt DESC LIMIT 3"
cdatacli query sql --connection asana --sql "SELECT Name, AssigneeName, DueOn FROM Tasks WHERE ProjectId = '12002…' AND Completed = false LIMIT 3"
{ "resultset": [
  { "Id": "12002…", "Name": "Content Calendar" },
  { "Id": "12056…", "Name": "Team Comms Hub" },
  { "Id": "12166…", "Name": "Q3 Planning" }
] }
{ "resultset": [
  { "Name": "Update analyst report landing pages", "AssigneeName": "A. Rivera",   "DueOn": "2026-07-29" },
  { "Name": "Refresh partner directory page",       "AssigneeName": "Unassigned",  "DueOn": "2026-08-11" },
  { "Name": "Draft Q3 use-case brief",              "AssigneeName": "J. Chen",     "DueOn": null }
] }
This is the key architectural moment. The SQL was validated here through the JDBC-backed CLI, and because every CData edition shares one data model, these exact statements run unchanged through the ADO.NET provider in the app.

Step 3: Handoff to the .NET build skill

The agent invoked cdata-cli-adonet and set up the .NET side: added the CData Asana ADO.NET provider from NuGet (a separate edition from the CLI's JDBC driver), plus Spectre.Console for the TUI, then activated the provider's license: 

dotnet add package CData.Asana
dotnet add package Spectre.Console
dotnet .\install-license.dll
Installing TRIAL license...
License installation succeeded.
A separate driver edition. The ADO.NET provider isn't the JDBC driver the CLI used. It's the .NET edition of the same driver, from NuGet, licensed independently. Same data model, different runtime.

Step 4: The build — write the TUI

The agent wrote a console TUI using the provider through standard ADO.NET (AsanaConnection / AsanaCommand, named @ parameters, and using blocks since ADO.NET objects are IDisposable). It reused the asana connection's cached OAuth token. The core is the validated queries plus a Spectre.Console tree: 

using System.Data.CData.Asana;

using var conn = new AsanaConnection(ConnectionString);
conn.Open();

// active projects
using var projects = new AsanaCommand(
    "SELECT Id, Name FROM Projects WHERE Archived = false ORDER BY ModifiedAt DESC LIMIT 5", conn);

// open tasks for one project — Asana filters Tasks by ProjectId
using var tasks = new AsanaCommand(
    "SELECT Name, AssigneeName, DueOn FROM Tasks WHERE ProjectId = @pid AND Completed = false", conn);
tasks.Parameters.Add(new AsanaParameter("@pid", projectId));

Step 5: Run it against real Asana

dotnet run -- --projects 5
Open tasks in your 5 most active Asana projects
├── Content Calendar  (34 open)
│   ├── 2026-07-25  Update analyst report landing pages   — A. Rivera      (overdue)
│   ├── 2026-07-29  Swap homepage hero copy               — Unassigned     (due soon)
│   └── 2026-08-11  Refresh partner directory page        — J. Chen
├── Team Comms Hub  (28 open)
│   └── 2026-08-02  Publish August newsletter             — A. Rivera
├── Q3 Planning  (15 open)
│   └── 2026-09-11  Finalize use-case brief               — S. Malik
└── Event Planning  (2 open)
    └── 2026-08-20  Confirm booth logistics               — J. Chen

118 open task(s) across 5 active project(s).

Due dates are color-coded (overdue red, due-within-a-week yellow). From "show my open Asana tasks in a C# TUI" to a working, schema-accurate app came out of one prompt, because the agent grounded itself with the CLI first, then built against the same data model through the ADO.NET provider.

Get started

The CData CLI turns any AI coding agent into one that can build real, data-connected .NET apps, grounded in your actual schema rather than a guess.

Download the CLI

macOS:

curl -fsSL https://downloads.cdata.com/cdatabuilds/builds/free/cdatacli/install-cdatacli-macos.sh | bash

Windows:

irm https://downloads.cdata.com/cdatabuilds/builds/free/cdatacli/install-cdatacli-windows.ps1 | iex

Linux:

curl -fsSL https://downloads.cdata.com/cdatabuilds/builds/free/cdatacli/install-cdatacli-linux.sh | bash

Download all CLI skills:

npx skills add CDataSoftware/cli-skills

Download the .NET CLI skill only:

npx skills add CDataSoftware/cli-skills --skill cdata-cli-adonet

Questions? Contact the support team.

In this article

Related articles