CLI Binary Wrappers📋

All nine wrapper families and BinaryWrapper itself are under intensive development. They bring existing executables into C# so that commands can be discovered in the IDE and composed with typed configurations. This is one of the infrastructure foundations being brought together through Diem toward a software factory Lab.

From Help Output to Execution📋

1. A design project obtains a tool version and collects its help output.
2. A parser builds a versioned command tree, saved as JSON.
3. Roslyn generates command types, builders and clients from those inputs.
4. A command produces an ordered argument array.
5. Runtime services resolve the executable and run the process.
6. Output parsers and collectors, where implemented, turn process output into events and results.

Generated types express the collected command model. Runtime compatibility still depends on the binary version, the accuracy of its help parser and the surrounding environment. A parser test, an argument test and a real process integration test establish different things. BinaryWrapper practical guide · Framework foundations.

Local Collection Snapshot📋

9 September 2026: JSON files directly inside each wrapper's src/FrenchExDev.Net.<family>/scrape directory, including files ignored by Git. These are collected snapshots; the counts do not certify successful execution against every version.

The examples below were checked against source and tests; those tests were not executed for this documentation update.

Podman📋

The Podman wrapper covers container-related command groups through Cobra help collection. Argument tests exercise boolean switches, names and repeated options. For example, Run_MultipleVolumes_SerializesEach constructs new PodmanRunCommand { Volume = ["/host:/container", "/data:/data"] } and checks that both --volume arguments are emitted.

This demonstrates serialization of repeated values. Running a container additionally requires a working Podman installation and the requested resources. Source and command tests↗ (ouvre dans une nouvelle fenêtre).

Docker Compose📋

The design pipeline collects Compose's Cobra help and feeds generated command APIs. The wrapper controls Compose operations; DockerCompose.Bundle describes the services being operated.

The wrapper's inspected test instantiates DockerComposeDescriptor. The separate bundle tests exercise configuration construction and serialization; neither that descriptor check nor the number of snapshots establishes a complete Compose lifecycle test. Source↗ (ouvre dans une nouvelle fenêtre) · Practical guide.

Vagrant📋

Vagrant requires a parser for headings such as Common commands: and Available subcommands:. Its runtime integration also interprets machine and provisioner output, then collects operation results.

In VagrantOutputParserTests, the line ==> default: Importing base box... becomes a VagrantMachineOutput with machine name default. Other cases exercise errors and completion events. These conversions support Vos; VM execution still needs Vagrant, the selected provider and a valid machine configuration. Source and tests↗ (ouvre dans une nouvelle fenêtre).

Packer📋

Packer's custom help parser and descriptor account for single-dash options and equals-separated values. The argument tests include this construction:

using FrenchExDev.Net.Packer;

var command = new PackerBuildCommand
{
    Force = true,
    ParallelBuilds = "4"
};

var arguments = command.ToArguments();
// Includes "-force=true" and "-parallel-builds=4".

This excerpt constructs arguments only; a build also needs a template, plugins and the underlying Packer executable. Pair the command layer with Packer.Bundle and Alpine provisioning. Source and tests↗ (ouvre dans une nouvelle fenêtre).

Podman Compose📋

This wrapper targets the Python podman-compose CLI. Its argparse help format has its own parsing path. The inspected consumer test creates PodmanComposeDescriptor; broader runtime compatibility needs integration checks for the selected Python package and Podman installation. Source↗ (ouvre dans une nouvelle fenêtre).

GitLab CLI📋

The glab integration combines GitLab release discovery, container-based collection and a custom help parser. Its concrete generator entry point is [BinaryWrapper("glab")] public partial class GlabDescriptor;.

This supplies command APIs for GitLab workflows. Authentication and the target GitLab instance are runtime dependencies. The inspected family contains the design and descriptor sources but no local test project; the collection count is therefore especially distinct from runtime validation. Source↗ (ouvre dans une nouvelle fenêtre).

Docker📋

Docker now has collected command trees, generator integration and serialization tests. For example, new DockerContainerRunCommand { Detach = true } is checked for a --detach argument, while omitted options produce no arguments.

Those tests describe the generated command model. Executing it requires a reachable Docker engine and appropriate runtime configuration. Source and tests↗ (ouvre dans une nouvelle fenêtre).

Git📋

The design pipeline builds selected Git versions from source inside an Alpine container before collecting help. GitHelpParser handles Git's command listings and help layout.

One root-discovery test provides Main Porcelain Commands and Ancillary Commands sections, then checks that five named commands are discovered in order. This exercises parsing without changing a repository. The collection pipeline separately needs its container image, compiler toolchain and source downloads. Source and parser tests↗ (ouvre dans une nouvelle fenêtre).

Dotnet📋

Dotnet adds a parser for SDK help sections, option values and positional arguments, including command-specific handling for NuGet and user-secrets. Tests also retain MSBuild's native colon syntax.

This excerpt from Build_PreservesFlagsAndProjectPathBoundaries constructs a command without running a build:

using FrenchExDev.Net.Dotnet;

var command = new DotnetBuildCommand
{
    Framework = "net8.0",
    Configuration = "Release",
    NoRestore = true,
    ProjectOrSolution = ["directory with spaces/project.csproj"]
};

var arguments = command.ToArguments();

The test compares the complete ordered array, then uses FakeProcessRunner to inspect execution arguments. The path containing spaces stays one argument. The net8.0 value comes from that test fixture; it does not describe the FrenchExDev repository's current targets. Source and tests↗ (ouvre dans une nouvelle fenêtre).

Back to the ecosystem · Next: typed configuration and bundles