FrenchExDev: A .NET & PowerShell Development Ecosystem
I build reusable tools for the work around software: typed command APIs, configuration models, generators and explicit checks. Start with the map and BinaryWrapper example, then follow the sources into the wider ecosystem.
Overview
Projects, CLI versions and configuration formats multiply. My aim is to make their recurring rules explicit, then reuse the machinery that interprets them: parsers, typed models, generators, serializers and checks.
Anything-as-Code is the approach. FrenchExDev is the ecosystem that implements it. This page connects the component map to an example, the extension process and the sources behind the catalogue.
| Name | Role |
|---|---|
| Requirements-as-Code | New requirements or experimental recovery of candidates; explicit verification relationships. |
| Diem | Give the C# application and infrastructure components a shared product direction. |
| HomeLab | The integration target: a development Lab described and controlled from a C# project. |
Explore the experimental path from existing code and tests →
Codebase boundaries. The C# and PowerShell work lives in the FrenchExDev repository under Net/FrenchExDev and PoSh/FrenchExDev. The TypeScript packages used by this CV site form a separate codebase. Requirements-as-Code explains its two implementations. They share a modeling approach; their builds, checks and inventories are separate.
The Component Map
The compiler checks the C# shape available to it. Parsers, serializers and runtime adapters have their own verification needs. Development practices separates source inspection, tests, coverage, mutation and CI enforcement.
A Concrete Example: BinaryWrapper
Versioned CLI description → generated C# API → argument array → verification.
The Dotnet integration supplies collected command trees and a [BinaryWrapper("dotnet", ...)] descriptor. The shared generator produces command types, including DotnetBuildCommand. A test supplies a project path containing spaces and compares every argument delivered to a simulated process.
Inspect the input, generated API, output and test →
That example makes one contract visible: the path stays a single argument. The linked walkthrough identifies the source, prerequisites and test command, together with the boundary between the simulated process and a real SDK invocation.
How a New Integration Extends the System
- Supply the tool-specific input. Discover the relevant versions and retain their CLI help or schemas.
- Reuse the model and generation pipeline. Select an existing parser where it fits; implement tool-specific parsing where the format requires it.
- Declare and consume the typed API. Add the descriptor and project references, or the configuration model and serializer.
- Check the boundary that changed. Verify parsing and generated compilation, compare complete argument arrays or serialized files, and run a real tool integration when the behavior depends on it.
Result, Builder, BinaryWrapper and the configuration tooling carry shared responsibilities. A new integration still needs its own inputs, format decisions and meaningful tests. Wrapper families · Configuration Bundles.
Current Implementation and Evidence
| Area | Available material | Development boundary |
|---|---|---|
| Libraries, wrappers and Bundles | Source references and examples in the component fiches | Runtime support depends on the tool, version and checks actually run. |
| Requirements-as-Code | TypeScript tooling used by this site; C# types and registry generation | The inspected C# coverage analyzer declares REQ100 without registering a coverage analysis action. |
| Diem and HomeLab | Application models, infrastructure contributors and a proposed composition model | Complete Lab lifecycle integration remains in development. |
| Ops DSL series | Design chapters, example declarations and intended reports | Execution of the complete 22-DSL sample has not been established by the linked material. |
The product target is MyLocalHost.Diem.Lab: a C# project describing a Lab tailored to my machine, bringing GitLab, CI and nodes together through these reusable parts. The Diem presentation and product, architecture and specification series develop that target.
The source inventory below is a dated observation. For operational evidence, follow the verification stages and the scope stated beside each example.
Source Snapshot
Local inventory refreshed on 9 September 2026:
| Scope | Count |
|---|---|
| First-level C# families containing projects | 45 |
| C# project files | 252 |
Project files under test or tests directories |
62 |
| PowerShell module manifests | 36 |
Counts cover the local Net/FrenchExDev and PoSh/FrenchExDev trees, including Git-ignored source inputs and excluding bin, obj and .git. A family can contain several libraries, generators, applications and tests; the catalogue therefore lists some components separately within one family.
The root declares SDK 11.0.100-rc.1.26425.128; targets encountered include net10.0, net11.0 and netstandard2.0. Build settings and boundaries.
These are source observations, not release or test-pass counts. The C# suites and infrastructure operations were not run for this documentation update. GitHub links point to the repository's develop paths; local changes described here may precede those public sources.
.NET Projects at a Glance
All entries remain in development. The linked fiches give source references, practical examples and the current implementation boundaries.
Values, Construction and Dependencies
| Component | Current role |
|---|---|
| Result | Explicit outcomes and composition |
| Options | Optional values, LINQ and Result integration |
| Union | Typed alternatives and matching |
| Guard | Throwing or Result-based validation |
| Builder | Generated construction APIs, validation and references |
| Injectable | DI registrations and lifetime diagnostics |
| Mapper | Mapping contracts, attributes and test assertions |
| Mediator | Request/handler contracts and a testing fake |
| Clock | TimeProvider integration and controlled test time |
| HttpClient | HTTP GET abstraction and sequential fake responses |
Workflows, Models and Product
| Component | Current role |
|---|---|
| FiniteStateMachine | Async transitions, guards, hierarchy and graph testing |
| Reactive | Event streams and test subscriptions |
| Saga | Workflow steps, compensation and store contracts |
| Outbox | Message storage contracts and EF Core integration |
| Dsl | Metamodel declarations and registry generation |
| Ddd | Domain declarations and invariant generation |
| Entity.Dsl | EF configurations, DbContext, repositories and units of work |
| Ddd.Entity.Dsl | Metadata bridge from domain to persistence models |
| Requirements | Requirement declarations and registry; coverage analyzer unfinished |
| Diem | Product/CMF DSLs; generators and Lab integration in progress |
Command APIs and Versioned Inputs
| Component | Current role |
|---|---|
| BinaryWrapper | Command generation and process execution infrastructure |
| Wrapper.Versioning | Collection, download, transformation and persistence of inputs |
| Podman | Container-tool command generation |
| Docker Compose | Compose command generation |
| Vagrant | VM commands, parsed events and operation collectors |
| Packer | Image-building command APIs |
| Podman Compose | Python CLI integration |
| GitLab.Cli | glab help collection and descriptor |
| Docker | Collected Docker command models and generated APIs |
| Git | Git collection and custom help parsing |
| Dotnet | SDK command parsing and argument-boundary tests |
Configuration and Infrastructure
| Component | Current role |
|---|---|
| DockerCompose.Bundle | Compose configuration models and serialization |
| Traefik.Bundle | Static/dynamic routing models and YAML/JSON |
| Packer.Bundle | Plugin model extraction and HCL2 |
| GitLab.Ci.Yaml | Pipeline models and YAML read/write |
| GitLab.DockerCompose | Omnibus models, Ruby rendering and service contributors |
| Alpine.Version | Alpine release discovery and filtering |
| VirtualBox.Version | Installed hypervisor version discovery |
| Packer.Alpine | Alpine installation and image provisioning |
| Packer.Alpine.DockerHost | Docker image contribution |
| Vos | Configuration, instance resolution and VM services |
| Vos.Alpine | Alpine/VirtualBox machine contribution |
| Vos.Alpine.DockerHost | Docker host machine contribution |
Applications and Research
| Component | Current role |
|---|---|
| Doc2Pdf | LibreOffice batch conversion CLI |
| DockAi | Ingestion, Lucene.Net search, AI adapters and ASP.NET Core viewer |
| QualityGate | Roslyn analysis, evidence imports and reports |
| IEC61499 | Experimental function-block models |
Part I: .NET Libraries
Model values, build objects and define application behavior: Result, Options, Union, Guard, Builder, dependency contracts, controlled HTTP/time, event workflows, DSLs, persistence and the current Requirements/Diem implementation.
Part II: CLI Binary Wrappers
Automate an executable through C#: nine families covering Podman, Docker Compose, Vagrant, Packer, Podman Compose, GitLab CLI, Docker, Git and Dotnet. Follow collection, generation, arguments, execution and output parsing.
Part III: Typed Configuration & Bundles
Produce configuration files from C# models: Compose and Traefik, Packer HCL2, GitLab CI YAML and GitLab Omnibus Ruby configuration.
Part IV: Infrastructure
Prepare images, describe machines and compose services: Alpine and VirtualBox version discovery, Packer contributions, Vos services and the intended Lab integration.
Part V: Applications
Use the current application implementations: LibreOffice batch conversion with Doc2Pdf, document ingestion/search with DockAi, and code analysis with QualityGate.
Part VI: PowerShell Modules
Work with the shell automation: development setup, source control, containers, VMs and local services. Module functions, standalone scripts and scaffolds are identified separately.
Part VII: Development Practices & Research
Build and assess the components: SDK policy, central packages, update tooling, tests, coverage, mutation and quality gates, plus IEC61499 experiments.
Design Philosophy
Make models explicit. Use types for values, commands, configuration and domain concepts; make validation and failure policies visible.
Compose focused components. Keep generation, serialization, process execution and application behavior behind clear contracts so that each can evolve with its consumers.
Keep automation inspectable. Retain collected inputs, generated artifacts, argument arrays and test evidence that explain what a tool is doing.
Connect the work to a product. Diem gives this ecosystem a direction: bring application models and infrastructure together until a personal software factory can be expressed and operated as a C# project.