FrenchExDev: A .NET & PowerShell Development Ecosystem
FrenchExDev is under intensive development across the whole stack: libraries, generators, binary wrappers, bundles, infrastructure, applications, PowerShell and Diem. These pages describe the work implemented so far and how it is intended to come together.
Overview
I am building reusable C# and PowerShell components for application development and the tools around it. Typed APIs make command options, configuration and domain models discoverable in the IDE; runtime adapters connect those models to files, processes and services.
I started Diem to give this work a product dimension and progressively bring the pieces together. Its application model develops alongside the binary wrappers and bundles used for infrastructure. The target is a software factory Lab with GitLab, GitLab CI and nodes, composed from those reusable parts.
At the point where they have sufficiently converged, I want to write MyLocalHost.Diem.Lab: my own C# project describing a Lab tailored precisely to my machine and running, for example, on my laptop. This is the destination of the work; the full integration is still being developed.
The following shows that intended convergence:
The Diem Lab presentation develops the product direction. Its documentation series proceeds through product presentation, usages/architecture and technical specification. In that proposed architecture the Lab is mandatory, while exposure and access controls are configurable.
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.
.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 |
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.
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.