Morphir.Ion 0.4.0-alpha.4

Prefix Reserved
This is a prerelease version of Morphir.Ion.
dotnet add package Morphir.Ion --version 0.4.0-alpha.4
                    
NuGet\Install-Package Morphir.Ion -Version 0.4.0-alpha.4
                    
This command is intended to be used within the Package Manager Console in Visual Studio, as it uses the NuGet module's version of Install-Package.
<PackageReference Include="Morphir.Ion" Version="0.4.0-alpha.4" />
                    
For projects that support PackageReference, copy this XML node into the project file to reference the package.
<PackageVersion Include="Morphir.Ion" Version="0.4.0-alpha.4" />
                    
Directory.Packages.props
<PackageReference Include="Morphir.Ion" />
                    
Project file
For projects that support Central Package Management (CPM), copy this XML node into the solution Directory.Packages.props file to version the package.
paket add Morphir.Ion --version 0.4.0-alpha.4
                    
#r "nuget: Morphir.Ion, 0.4.0-alpha.4"
                    
#r directive can be used in F# Interactive and Polyglot Notebooks. Copy this into the interactive tool or source code of the script to reference the package.
#:package Morphir.Ion@0.4.0-alpha.4
                    
#:package directive can be used in C# file-based apps starting in .NET 10 preview 4. Copy this into a .cs file before any lines of code to reference the package.
#addin nuget:?package=Morphir.Ion&version=0.4.0-alpha.4&prerelease
                    
Install as a Cake Addin
#tool nuget:?package=Morphir.Ion&version=0.4.0-alpha.4&prerelease
                    
Install as a Cake Tool

FINOS - Incubating Slack Development Workflow Deployment Workflow CVE Scanning NuGet Version NuGet Core NuGet Tooling Proto Plugin <img src="https://github.com/finos/branding/blob/master/project-logos/active-project-logos/Morphir%20Logo/Horizontal/2020_Morphir_Logo_Horizontal.png?raw=true" width="450">

Morphir

Morphir is a library of tools that works to capture business logic as data.

For the first time, business logic can be shared, stored, translated and visualised, all with the reliability of standardisation ensured in the Morphir framework.

What is it?

A set of tools for integrating technologies. Morphir is composed of a library of tools that facilitate the digitisation of business logic into multiple different languages & platforms. The Morphir framework is unique too in that facilities elements of automation and conversion that were previously unavailable in the field of finance-tech.

Why is it important?

Makes business logic portable. Business logic digitised provides distinct advantages: capacity for movement across departments and fields & the ability to be converted to new languages and applications.

How does it work?

Defines a standard format for storing and sharing business logic. A clear set of standards and format is in-place from the input/output, allowing for coherent structure.

What are the benefits?

✔️ Eliminates technical debt risk

Refactoring code libraries is often a harmful and time-sensitive issue for businesses, Morphir ensure the standards introduced from input eliminate delays at deployment.

✔️ Increases agility

Adaptability and usability are key concepts of the Morphir framework, business logic can now move with the code, be easily understood and adopted, in an ever-developing eco-system.

✔️ Ensures correctness

Certifying that specified functions behave as intended from input to output is assured through the Morphir library / tool chain.

✔️ Disseminates information through automation

Morphir’s automated processing helps disseminate information which otherwise may not be understood or shared at all, a useful tool when brining elements of business logic to conversation outside of its immediate audience (i.e developers).

Morphir .NET

Provides tooling for the Morphir ecosystem and .NET libraries that can be used to help you work with Morphir.

The additive shared configuration libraries provide typed TOML, YAML, JSON/JSON5 documents, pure source resolution, named profiles, validation and winning origins without constructing the CLI. Morphir.Configuration.IO reads explicit files or supplied text and exposes bounded project/workspace discovery through native and in-memory trees. See the discovery guide for ProjectSystem.Discover, per-root/member ProjectSystem.Load, membership/selection, host boundaries and explicitly authorized machine sources. Existing Git-first artifact discovery, cache-only tooling and CI overlays keep their compatibility behavior. Shared inspection APIs and morphir config get/list/show/path/explain expose typed values, source reports, scoped queries and redacted explanations. The optional Microsoft adapter projects one resolved document with explicit/source-generated Options binding. See the CLI reference for read controls, JSON schema and exit codes. Shared editing services and morphir config set/unset provide typed, scoped TOML previews and writes, source-preserving changes, optimistic conflicts and explicit recovery ownership. Shared classic project migration and morphir project migrate provide loss-checked previews and guarded TOML adoption while retaining classic bytes. Shared workspace migration adds bounded inventory, verified membership and recoverable batch application through morphir workspace migrate [directory]. See the reader profile for syntax and provenance.

SDK libraries

Morphir.SDK.CSharp is an independent net10.0 runtime package with immutable C#/.NET public types. See the C# SDK guide for its bounded operation contract and package usage.

The in-memory C# generator lowers typed classic/v4 libraries with explicit numeric C# 14/15 profiles, immutable values, executable functions/patterns/record operations and public SDK bindings. Original business fixtures and the bounded modern package-host/trimming checks are verified under #474. Implementation #478 landed. The main specification and archived acceptance evidence landed in archive follow-up #480. Coordinator cleanup remains pending.

Generate C# through the existing CLI, with numeric profiles and a validated optional namespace:

morphir generate --input model.json --target csharp --output generated --option language-version=14 --option namespace=Example.Generated --json

The C# walkthrough builds and runs a fresh consumer against the immutable runtime. CLI implementation #482 landed; its main specification and archived evidence are synchronized in this follow-up. Archive PR landing and root-verified cleanup remain pending.

Getting Started

Building from source

All projects target .NET 10 LTS. Install the SDK pinned in global.json, or use mise install to install the tools in mise.toml. CI uses the same SDK pin.

VS Code users can run Dev Containers: Reopen in Container to use the Microsoft .NET SDK image in .devcontainer/Dockerfile. The SDK includes the C# and F# compilers. Renovate groups the container, global.json, and mise SDK updates together and keeps them on .NET 10 LTS. Moving to the next LTS major version requires an explicit baseline update.

./build.sh --target Test
./build.sh --target PackAll
./build.sh --target TestBuild

To compile classic Morphir model JSON into F#, see the Myriad getting-started article, plugin reference, and car rental tutorial. The runnable example covers inventory, reservation, pickup, return and billing with one generated F# file per module.

Quick Start

Install Morphir using one of the following methods:

Using proto (Recommended for multi-language toolchains):

# Install proto (if not already installed)
curl -fsSL https://moonrepo.dev/install/proto.sh | bash  # Linux/macOS
# or: irm https://moonrepo.dev/install/proto.ps1 | iex  # Windows

# Add Morphir plugin and install
proto plugin add morphir "source:https://github.com/finos/morphir-dotnet/releases/latest/download/morphir_plugin.wasm"
proto install morphir

Using Platform-Specific Install Scripts:

# Linux
curl -fsSL https://raw.githubusercontent.com/finos/morphir-dotnet/main/scripts/install-linux.sh | bash

# macOS
curl -fsSL https://raw.githubusercontent.com/finos/morphir-dotnet/main/scripts/install-macos.sh | bash

# Windows (PowerShell)
irm https://raw.githubusercontent.com/finos/morphir-dotnet/main/scripts/install-windows.ps1 | iex

Using .NET Tool (requires .NET SDK):

dotnet tool install --global Morphir.Tool --prerelease

Verify Installation:

morphir --version          # native executable
dotnet-morphir --version   # .NET tool

Compile F# to Morphir IR: follow the five-minute Compile F# guide.

For detailed installation instructions and troubleshooting, see the Installation Guide.

Documentation

Building

This project uses Nuke for build orchestration, providing a strongly-typed, cross-platform build system written in C#.

Requirements

  • .NET SDK 10.0.403 or a later patch in the same feature band, as specified in global.json

Basic Commands

# First-time setup: Restore tools and dependencies
dotnet tool restore
./build.sh --target Restore

# Build the solution (default target)
./build.sh

# Run tests
./build.sh --target Test

# Run linting/formatting checks
./build.sh --target Lint

# Format code
./build.sh --target Format

# Run full CI pipeline (restore, build, test, lint)
./build.sh --target CI

# Show all available targets
./build.sh --help

Windows users: Use build.cmd or build.ps1 instead of ./build.sh

Configuration

You can set the build configuration using the --configuration parameter:

# Build in Debug mode
./build.sh --configuration Debug

# Run tests in Debug mode
./build.sh --target Test --configuration Debug

By default, commands use Release configuration.

Migration from Just

This project was recently migrated from Just to Nuke. See NUKE_MIGRATION.md for the complete migration guide and command mappings. The old justfile is preserved for reference.

Developing

The shared .NET SDK contract freezes the bounded operation signatures, scalar limits and independent expectations used by both SDK deliveries. See the fixture guide for the build command, schema and provenance. After building its test project, run the offline validator with:

dotnet exec tests/Morphir.SDK.Conformance.Tests/bin/Debug/net10.0/Morphir.SDK.Conformance.Tests.dll --maximum-parallel-tests 2

F# runtime consumers use Morphir.SDK.FSharp. Its namespace and runtime assembly remain Morphir.SDK, so existing generated source and runtime type identities remain valid. The legacy Morphir.SDK package depends on the canonical package and ships no runtime assembly. See the F# runtime migration guide for dependency selection and covered behavior corrections.

Project Structure

morphir-dotnet/
├── src/
│   ├── Morphir.Core/          # Core IR types and utilities
│   ├── Morphir.Tooling/       # Tooling infrastructure
│   └── Morphir/               # CLI application
├── tests/
│   ├── Morphir.Core.Tests/    # Unit tests for Core
│   ├── Morphir.Tooling.Tests/ # Unit tests for Tooling
│   └── Morphir.E2E.Tests/     # End-to-end tests (BDD/Gherkin)
├── build/
│   ├── _build.csproj          # Nuke build project
│   └── Build.cs               # Build orchestration (strongly-typed)
├── scripts/                   # Build and utility scripts (C# scripts)
├── build.sh/cmd/ps1           # Nuke bootstrap scripts
└── justfile                   # Legacy build commands (preserved for reference)

Development Workflow

  1. Restore dependencies:

    ./build.sh --target Restore
    
  2. Build the solution:

    ./build.sh --target Compile
    
  3. Run tests:

    ./build.sh --target Test
    
  4. Check code formatting:

    ./build.sh --target Lint
    
  5. Format code (if needed):

    # Unix/macOS
    ./build.sh --target Format
    
    # Windows
    build.cmd --target Format
    # or
    ./build.ps1 --target Format
    

Scripts

The project uses C# scripts (.cs files) for build automation, leveraging .NET 10's direct C# file execution. These scripts are located in the scripts/ directory:

  • run-tests.cs - Runs unit tests
  • run-e2e-tests.cs - Runs end-to-end tests
  • generate-wolverine-code.cs - Generates Wolverine code

Note: The deprecated build-tool-dll.cs, pack-tool-platform.cs, publish-single-file.cs and publish-single-file-untrimmed.cs scripts have been removed. Use the Nuke build targets (PackTool, PublishTool, PackRelease, PublishSingleFile, PublishSingleFileUntrimmed) instead.

Build Commands

All Nuke build commands support both Unix/macOS (./build.sh) and Windows (build.cmd or ./build.ps1) bootstrap scripts. Examples below show both formats.

Building Libraries
# Unix/macOS: Pack library projects as NuGet packages
./build.sh --target PackLibs

# Windows
build.cmd --target PackLibs
# or
./build.ps1 --target PackLibs

# Pack all projects (libraries and tool)
./build.sh --target PackAll                  # Unix/macOS
build.cmd --target PackAll                   # Windows

# Specify configuration and version
./build.sh --target PackLibs --configuration Debug --version 1.2.3
build.cmd --target PackLibs --configuration Debug --version 1.2.3

# Custom output directory
./build.sh --target PackLibs --output-dir ./my-packages
build.cmd --target PackLibs --output-dir ./my-packages
Building Release Profiles

The four .NET deployment offerings each have a named release profile. PackRelease publishes one profile for one platform and packs it into an archive named morphir-dotnet-<release>-<deployment>-<rid>.<zip|tar.gz> (zip on Windows, tar.gz elsewhere, files at the archive root), or for dotnet-tool the Morphir.Tool.<release>.nupkg package. The release comes from CHANGELOG.md. Output goes to artifacts/release/; the publish folders are in artifacts/release/publish/<deployment>/<rid>/.

# Native AOT morphir (src/Morphir). Build on the operating system of the RID.
./build.sh --target PackRelease --deployment native-aot --rid linux-x64
build.cmd --target PackRelease --deployment native-aot --rid win-arm64

# Managed morphir with the in-process F# frontend (src/Morphir.Managed), untrimmed folder archives
./build.sh --target PackRelease --deployment self-contained --rid osx-arm64
./build.sh --target PackRelease --deployment framework-dependent --rid linux-arm64

# The Morphir.Tool package (dotnet-morphir). Portable, so no --rid.
./build.sh --target PackRelease --deployment dotnet-tool

# Publish only, without the archive
./build.sh --target PublishRelease --deployment self-contained --rid win-x64

Platforms: win-x64, win-arm64, osx-x64, osx-arm64, linux-x64, linux-arm64. Any other RID is refused. Beside each archive, <archive>.build-launch.json records its launch path, execution mode, layout (single-file, folder or tool-package), bundled runtime, required runtime or SDK, F# frontend, prerequisites and SHA-256. The operating-system prerequisites are not declared yet; qualifying the artifact on each platform establishes them. It is a build output, not a public contract. PackRelease fails when the publish folder contradicts it, for example a framework-dependent folder that carries coreclr. Building a profile does not qualify a platform: no platform is release-qualified yet.

The same publish folder always gives the same archive bytes. A publish for one RID writes its NuGet lock files under obj/publish-lock/<rid>/, so it leaves the committed packages.lock.json files alone. To check, run git status --short before and after PackRelease: it should list nothing new outside artifacts/, which is ignored.

On Windows, the Native AOT link needs the Visual Studio C++ build tools for the target architecture, and the ILCompiler targets call vswhere.exe. If the link fails with "'vswhere.exe' is not recognized", put %ProgramFiles(x86)%\Microsoft Visual Studio\Installer on PATH in that shell.

Building Executables

These targets keep the layouts that the workflows and E2E tests use. PublishSingleFile builds the legacy release asset that releases ship as morphir-<rid>[.exe] and morphir-<rid>-v<version>.tar.gz.

# Build a trimmed single-file executable for a specific platform
./build.sh --target PublishSingleFile --rid linux-x64        # Unix/macOS
build.cmd --target PublishSingleFile --rid linux-x64         # Windows

# Build an AOT (ahead-of-time compiled) executable
./build.sh --target PublishExecutable --rid linux-x64
build.cmd --target PublishExecutable --rid linux-x64

# Build an untrimmed executable (larger, better for debugging)
./build.sh --target PublishSingleFileUntrimmed --rid win-x64
build.cmd --target PublishSingleFileUntrimmed --rid win-x64

# Common RIDs: linux-x64, linux-arm64, win-x64, osx-x64, osx-arm64

# With custom configuration and output directory
./build.sh --target PublishSingleFile --rid linux-x64 --configuration Debug --single-file-dir ./bin
build.cmd --target PublishSingleFile --rid linux-x64 --configuration Debug --single-file-dir ./bin
Building the Dotnet Tool
# Pack the Morphir CLI as a dotnet tool
./build.sh --target PackTool                                  # Unix/macOS
build.cmd --target PackTool                                   # Windows

# With version and output directory
./build.sh --target PackTool --version 2.0.0 --output-dir ./packages
build.cmd --target PackTool --version 2.0.0 --output-dir ./packages
Testing
# Run unit tests
./build.sh --target Test                                      # Unix/macOS
build.cmd --target Test                                       # Windows

# Run tests in Debug configuration
./build.sh --target Test --configuration Debug
build.cmd --target Test --configuration Debug

# Build E2E test project
./build.sh --target BuildE2ETests
build.cmd --target BuildE2ETests

# Run end-to-end tests
./build.sh --target TestE2E                                   # Unix/macOS
build.cmd --target TestE2E                                    # Windows

# Run E2E tests for specific executable type (aot, trimmed, untrimmed, or all)
./build.sh --target TestE2E --executable-type trimmed
build.cmd --target TestE2E --executable-type trimmed
Publishing to NuGet
# Publish library packages to NuGet.org
./build.sh --target PublishLibs --api-key YOUR_API_KEY       # Unix/macOS
build.cmd --target PublishLibs --api-key YOUR_API_KEY        # Windows

# Publish the Morphir CLI tool package to NuGet.org
./build.sh --target PublishTool --api-key YOUR_API_KEY
build.cmd --target PublishTool --api-key YOUR_API_KEY

# Publish all packages
./build.sh --target PublishAll --api-key YOUR_API_KEY
build.cmd --target PublishAll --api-key YOUR_API_KEY

# Publish to custom NuGet source
./build.sh --target PublishLibs --nuget-source https://custom-feed.com --api-key YOUR_KEY
build.cmd --target PublishLibs --nuget-source https://custom-feed.com --api-key YOUR_KEY

# Publish to local NuGet feed (for testing)
./build.sh --target PublishLocalLibs                          # Unix/macOS
build.cmd --target PublishLocalLibs                           # Windows

# With custom local source
./build.sh --target PublishLocalLibs --local-source ./my-local-feed
build.cmd --target PublishLocalLibs --local-source ./my-local-feed

# Install tool locally from package
./build.sh --target PublishLocalTool
build.cmd --target PublishLocalTool

# Install globally
./build.sh --target PublishLocalTool --global true
build.cmd --target PublishLocalTool --global true

Available Nuke Targets

Run ./build.sh --help (Unix/macOS) or build.cmd --help (Windows) to see all available targets with descriptions and parameters.

Key targets:

  • Restore - Restore .NET dependencies
  • Compile - Build the solution (default target)
  • Test - Run unit tests
  • Lint - Check code formatting
  • Format - Format code
  • CI - Run full CI pipeline (restore, build, test, lint)
  • PackLibs - Pack library projects as NuGet packages
  • PackTool - Pack the Morphir CLI as a dotnet tool
  • PackAll - Pack all projects (libraries and tool)
  • PublishRelease - Publish one release profile (requires --deployment, and --rid except for dotnet-tool)
  • PackRelease - Pack one release profile into its named archive and launch metadata
  • PublishSingleFile - Publish the legacy trimmed single-file release asset (requires --rid)
  • PublishExecutable - Publish AOT executable (requires --rid)
  • PublishSingleFileUntrimmed - Publish untrimmed single-file executable (requires --rid)
  • TestE2E - Run end-to-end tests
  • PublishLibs - Publish library packages to NuGet
  • PublishTool - Publish tool package to NuGet
  • PublishAll - Publish all packages to NuGet
  • PublishLocalLibs - Publish libraries to local feed
  • PublishLocalTool - Install tool locally from package
  • PublishLocalAll - Publish all to local feed

Contributing

We welcome contributions! Please see our Contributing Guide for details.

License

This project is licensed under the Apache License 2.0 - see the LICENSE file for details.

SDK runtime delivery and archival evidence is recorded in the runtime delivery record. The canonical C# runtime spec, F# package spec, and stable C# API handoff describe the landed runtimes. SDK archive #472 landed; source SDK worktrees and their owned artifacts were removed. Empty shared archive directory cleanup remains pending with the recorded permission/policy limitations.

OpenSpec change proposals

The Morphir Compatibility Kit seed contains portable F# frontend cases, a closed step vocabulary and the deterministic library runner. Its reader/runner tests and Native AOT smoke check are independent of the production F# frontend, which is still being implemented.

This repository uses the shared html-design OpenSpec workflow. New proposals produce capability specs, a standalone design.html, and implementation tasks. See the OpenSpec guide for setup, verification and updates.

Product Compatible and additional computed target framework versions.
.NET net10.0 is compatible.  net10.0-android was computed.  net10.0-browser was computed.  net10.0-ios was computed.  net10.0-maccatalyst was computed.  net10.0-macos was computed.  net10.0-tvos was computed.  net10.0-windows was computed. 
Compatible target framework(s)
Included target framework(s) (in package)
Learn more about Target Frameworks and .NET Standard.

NuGet packages (1)

Showing the top 1 NuGet packages that depend on Morphir.Ion:

Package Downloads
Morphir.Tooling

Package Description

GitHub repositories

This package is not used by any popular GitHub repositories.

Version Downloads Last Updated
0.4.0-alpha.4 45 11/10/2026
0.4.0-alpha.3 58 11/9/2026
0.4.0-alpha.2 60 11/8/2026
0.4.0-alpha.1 61 11/7/2026

### Added

- `morphirup`, the standalone Native AOT toolchain manager, first slice: `morphirup --version`, plan-only `morphirup setup --plan` and `morphirup doctor` over local files. It needs neither .NET, ICU nor OpenSSL: it runs in invariant globalization mode, normalizes to NFC with its own Unicode 17.0.0 tables and computes SHA-256 with BouncyCastle's managed implementation. Setup resolves a `.morphir/toolchain.toml` request against a recipe file for every platform the lock would record and prints the plan with its `planSha256`. The plan carries the complete lock setup would write, so the digest pins every platform's closure and the request's exact bytes; `--expect-plan` refuses another plan with `plan_changed`. `--repository-id` is copied into the plan and lock as given and not checked, and the plan's sources are labels, not verified provenance. Without `--request`, the project request is discovered from the start directory up to the discovery boundary, by default the root of the file system; discovery stops at a `.morphir/toolchain.toml` in any form, and anything there that is not a readable regular file is `document_unavailable`. Doctor reads the lock beside the request it found or was given, and checks that the lock binds the request bytes, records the current platform and, with `--recipe` and `--repository-id`, names that repository (`repository_mismatch`) and is a closure the recipe allows. A request whose bytes differ from the locked ones only by CRLF line endings or a byte order mark is `request_changed` naming that cause. `setup --plan` and `doctor` write one manager result document to stdout. Files are read only when they are regular files, up to 1 MiB for a request, lock or sizes file and 16 MiB for a recipe, with five seconds to open and thirty seconds for each read; read errors are reported in `morphirup`'s own words, and a request, lock or recipe that cannot be read is `document_unavailable`. A document nested deeper than 64 levels is `invalid_document`. Acquisition, installation and activation are not implemented. Exit code 2 means the command was not run, for example an unknown option, a missing `--recipe` or `--repository-id`, an invalid option value, a machine that is not one of the eight platforms, or an artifact with no size in `--artifact-sizes`; it writes nothing to stdout. Provisional: `--project`, `--boundary`, `--recipe`, `--repository-id`, `--recipe-target`, `--artifact-sizes`, `--request` and `--lock`; the file bounds; the version bound (256 characters, 15 digits per numeric identifier, refused as `invalid_value`); and exit code 3 (internal error), which writes nothing to stdout ([#558](https://github.com/finos/morphir-dotnet/issues/558))
- Releases attach `morphirup` for `linux-x64`, `linux-arm64`, `win-x64` and `osx-arm64`: the executable `morphirup-<rid>` (`morphirup-win-x64.exe` on Windows), the archive `morphirup-<rid>-v<version>.tar.gz` with the executable, `LICENSE`, `NOTICE` and `THIRD-PARTY-NOTICES.txt` under `<rid>/`, the same notices as `morphirup-v<version>-THIRD-PARTY-NOTICES.txt`, and the checksum file `morphirup-v<version>.sha256` in `sha256sum -c` format. The notices are generated from the assemblies the Native AOT compiler linked, with each package's license and notice files; the build fails when a linked package has no license text. The release job builds each with Native AOT on a runner of its platform and runs the published file, not a source build, from a folder whose path has a space, with `PATH` reduced to the system folders and no `DOTNET_*` variable: it must print the release version and make a plan-only setup with the recorded plan digest. The Linux executables are linked in `ubuntu:22.04`, pinned by digest, so they need glibc 2.35 or later (Ubuntu 22.04, Debian 12 or later); the release job fails if one needs a newer glibc version, and runs each in `debian:12-slim` and `ubuntu:22.04` (with its `libssl3` package removed), with no .NET, `libicu`, `libssl` or `libcrypto`. A Linux executable needs nothing else from the machine. They do not run on musl distributions such as Alpine. Nothing else is checked. The files are not code-signed and the macOS file is not notarized, so Gatekeeper can refuse a copy that a browser downloaded until its quarantine attribute is removed; this was not checked on a Mac. The release does not download, install, update or activate a toolchain and does not verify signed metadata. The pull request workflow `morphirup` runs the same build and check on all four platforms ([#558](https://github.com/finos/morphir-dotnet/issues/558))
- `Morphir.Toolchain`: readers and writers for the `0.1.0-draft.1` toolset recipe, project toolchain request, portable lock, installation receipt and manager result of finos/morphir, with pure resolution, lock, plan and project discovery functions, pinned to finos/morphir `1451c081f`. A provider's `protocolVersion` is a MEP version on the supported 0.2 line (every prerelease of `0.2.0` and every final `0.2.x`); MEP `0.1` is refused, and an external provider carries one `modelTuple` and no `modelInput` or `modelOutput`. Plan digests and target paths are normalized to NFC with the library's own Unicode 17.0.0 tables, generated by `scripts/generate-nfc-tables.fsx` and checked against all of `NormalizationTest.txt`, so neither depends on the machine's ICU. It runs every case of the pinned finos/morphir contract manifests that is a pure function of documents and authenticated metadata. The cases that need a TUF client to verify metadata, or the installation work of later slices, are skipped by name with their reason ([#558](https://github.com/finos/morphir-dotnet/issues/558))
- The F# frontend extension `morphir-fsharp-frontend` has a self-contained process delivery: a folder with the guest, the F# compiler service and its own .NET runtime, published with the `SelfContainedProcess` profile or the build target `PublishFSharpFrontendProcess --rid <rid>`, which also writes a zip or `.tar.gz` archive (files at the root, ordinal order, fixed time stamp and modes) and keeps the publish's lock file beside it. A host such as the native `morphir` starts it with `--extension`. Checked on Windows ARM64 only, in an environment that hides the machine's .NET (no `dotnet` on `PATH`, no `DOTNET_*` variables, an empty NuGet folder and no global install): the automated test runs the guest there, and the native `morphir` compiled F# through it there by hand. It was not run on a machine with no .NET at all. Releases do not publish it yet. The framework-dependent dotnet tool is unchanged
- `morphir-fsharp-backend`: the F# generator as a MEP `0.2.0-draft.1` guest, packaged as the framework-dependent dotnet tool `Morphir.CodeGeneration.FSharp.Extension` with the extension id `org.finos.morphir.fsharp-backend`. It serves `morphir.backend.generateModel` for the target `fsharp` with JSON model tuples for IR `4.0.0` and `3.0.0`, for hosts that have no built-in F# backend. The built-in `morphir.fsharp` stays the backend of `morphir generate`, which does not start the extension. Releases publish the package next to `Morphir.Tool`
- `Morphir.Mep` backend messages: the pinned `generateModel` request, generate result and artifact types, and `GenerateModel.admit`, the guest check of a request. Compatibility note for F# code that opens `Morphir.Mep`: like the other wire types, the new records `GenerateModelRequest`, `GenerateResult`, `Artifact` and `AdmittedGenerateRequest` are at the top level of the namespace, and their labels (`Model`, `Input`, `Target`, `Options`, `Path`, `Content`, `Binary`, `Success`, `Artifacts`, `Diagnostics`, `Request`, `Guarantees`) can change which record type F# infers for an unannotated record expression or member access. Annotate the record type where that happens. The type name `Artifact` also exists as `Morphir.Conformance.Artifact`; qualify it when both namespaces are open
- `MorphirApplication` in `Morphir.Tooling`: the shared command layer (the scenarios, `info` and `--version`) that every entry point runs. `Morphir.Program.Run` and `Morphir.Program.CreateApp` keep their signatures and delegate to it
- A managed `morphir` entry point (`src/Morphir.Managed`) and the managed composition it shares with `dotnet-morphir` (`src/Morphir.Tooling.Managed`), which holds the in-process F# frontend. It is not packaged or released yet
- Build: named release profiles for the four .NET deployment offerings. `PublishRelease` and `PackRelease` with `--deployment native-aotself-containedframework-dependentdotnet-tool` and `--rid` produce `artifacts/release/morphir-dotnet-<release>-<deployment>-<rid>.<ziptar.gz>` (or `Morphir.Tool.<release>.nupkg`) with a build-side `.build-launch.json` beside it, for win-x64, win-arm64, osx-x64, osx-arm64, linux-x64 and linux-arm64. The managed profiles are untrimmed folders with the in-process F# frontend. The same publish folder always gives the same archive bytes (fixed time stamp, ordinal entry order, mode 0755 for the launch file and `createdump`, 0644 otherwise). `PackRelease` fails when the publish folder contradicts the launch metadata, and checks the tool package as `PackTool` does. A release with build metadata (`1.2.3+abc`) is refused. Releases do not publish these archives yet, and no platform is qualified yet ([#558](https://github.com/finos/morphir-dotnet/issues/558))

### Changed

- `dotnet-morphir` runs the shared command layer with the managed composition and no longer references the AOT-compatible `morphir` project, so the tool package no longer contains `morphir.dll`. Its commands and its F# frontend are unchanged
- Build: `PublishExecutable`, `PublishSingleFile` and `PublishSingleFileUntrimmed` take their settings from the release profile model. `PublishSingleFile` keeps the settings and names of the legacy release assets `morphir-<rid>[.exe]` and `morphir-<rid>-v<version>.tar.gz`. `PublishExecutable` now leaves out debug symbols and documentation files, and finds `morphir` (not `Morphir`) on Linux and macOS. Size figures of `PublishExecutable` output from before this change included the symbol file, so they are not directly comparable with new figures ([#558](https://github.com/finos/morphir-dotnet/issues/558))
- Build: publishes for one runtime identifier write their NuGet lock files under `obj/publish-lock/<rid>/` (the `MorphirRidSpecificPublish` property), so they no longer add RID sections to the committed `packages.lock.json` files ([#558](https://github.com/finos/morphir-dotnet/issues/558))
- Build: `src/Morphir.Managed` fails to build with `PublishAot` or `PublishTrimmed`, and a project whose references resolve two different `morphir.dll` assemblies (`src/Morphir` and `src/Morphir.Managed`) fails to build
- `just publish-executable`, `just publish-single-file` and `just publish-single-file-untrimmed` run the Nuke targets; their `VERSION` argument is gone, as the version comes from `CHANGELOG.md`. `scripts/measure-compile-aot.sh` publishes with the native-aot profile's settings

### Removed

- `scripts/publish-single-file.cs` and `scripts/publish-single-file-untrimmed.cs`, which called a removed `codegen write` command. Use the `PublishSingleFile` and `PublishSingleFileUntrimmed` targets ([#558](https://github.com/finos/morphir-dotnet/issues/558))

### Fixed

- The F# frontend takes its framework references from the framework's runtime assembly list, so in a self-contained folder it no longer gives the compiler the application's own assemblies (`Morphir.*`, the compiler service). The references of the dotnet tool and the in-process frontend are unchanged. It reads the deps files that the host lists (`APP_CONTEXT_DEPS_FILES`, joined with `;` on every platform). When it cannot give the compiler its references (no file location, a self-contained folder without a framework list, no trusted platform assemblies, or a listed deps file that cannot be read), compilation fails with one `fsharp.references_unavailable` error instead of an exception
- `Morphir.Myriad.SystemTextJson` build targets: an absolute `IntermediateOutputPath` (for example with `--artifacts-path`) no longer gives an invalid output folder for the generated JSON contexts