1 - Project Types
Project Types
There are five kinds of project in and around XRUIOS. They differ mostly in what they reference and how they start; the security contract underneath is the same. This section has a page for each with its exact .csproj, the DLLs and packages it needs, and why each one is there.
| Type | SDK | TFM | It is… | Entry point |
|---|---|---|---|---|
| Worker | Microsoft.NET.Sdk.Web |
net10.0 | one system class, isolated in its own process, exposing a curated capability surface | SecureWorkerHost.Run(...) |
| CMD app | Microsoft.NET.Sdk |
net10.0 | a headless program that calls capabilities through the broker | EclipseSecureClient.ConnectAsync(...) |
| Desktop app | Microsoft.NET.Sdk (+ WPF/Avalonia) |
net10.0-windows / net10.0 | the same broker client behind a window | a service the UI binds to |
| Aether mod | Microsoft.NET.Sdk |
net8.0 | untrusted code loaded under CasCore, gated by the same permission store | host loads it; mod asks the host |
| Diagnostics | Microsoft.NET.Sdk |
net10.0 | a broker client that probes every worker and asserts the walls | EclipseSecureClient.ConnectAsync(...) |
The reference matrix
What each project type actually pulls in. "Project" = a ProjectReference in this solution; "DLL" = a Reference with a HintPath into libs/; "Package" = a NuGet PackageReference.
| Reference | Worker | CMD app | Desktop | Aether host | Diagnostics |
|---|---|---|---|---|---|
XRUIOS.SecureLayer (project) |
● | ● | ● | ● | |
XRUIOS.Contracts / Core / Interfaces (project) |
● | ||||
YuukoProtocol.XRUIOS.Interfaces (project) |
● | ||||
EclipseProject.dll |
● | ● | ● | ● | |
PariahCybersecurity.dll |
● | ● | |||
KeeperOfTomes.dll / Secure Store.dll |
● | ●¹ | |||
PermissionHandler.dll |
● | ||||
| The Barebones package set | ● | ||||
| Pariah store transitives (Ceras, BouncyCastle, …) | ●² | ● | |||
Spectre.Console (package) |
○ | ○ | ● | ||
DouglasDwyer.CasCore (package) |
● | ||||
| CasSandbox + Security (project, Aether repo) | ● |
● required ○ optional (only if you use it). ¹Secure Store.dll for the Aether host's store. ²the worker gets these transitively through Directory.Build.props.
The one rule that never changes
Whatever the shell, the app never holds the authority - it holds a capability and asks. A worker only ever receives its own key and PSK; an app only ever gets its Manager-minted id and PSK; a mod gets neither and asks the host. If a project you're writing wants to reach a key, a socket to another worker, or the OS directly, it's built wrong - route it through the broker (apps/workers) or the host (mods). See 1 - The Model.
Start with the type you're building:
- 2 - A Worker - the biggest one; a new system class becomes a worker here.
- 3 - A CMD App - the smallest client; the reference shell.
- 4 - A Desktop App - the client behind a window.
- 5 - An Aether Mod - untrusted code, same gate.
- 6 - The Diagnostics Harness - the fleet self-test.