Morphir.Mep 0.4.0-alpha.4

Prefix Reserved
.NET 10.0 This package targets .NET 10.0. The package is compatible with this framework or higher.
This is a prerelease version of Morphir.Mep. 
dotnet add package Morphir.Mep --version 0.4.0-alpha.4
                    


                    

                
NuGet\Install-Package Morphir.Mep -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.Mep" 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.Mep" Version="0.4.0-alpha.4" />
                    


                            Directory.Packages.props
                        

                    

                
<PackageReference Include="Morphir.Mep" />
                    


                            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.Mep --version 0.4.0-alpha.4
                    


                    

                
#r "nuget: Morphir.Mep, 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.Mep@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.Mep&version=0.4.0-alpha.4&prerelease
                    


                            Install as a Cake Addin
                        

                    

                
#tool nuget:?package=Morphir.Mep&version=0.4.0-alpha.4&prerelease
                    


                            Install as a Cake Tool

Morphir.Mep

One implementation of the Morphir Extension Protocol (MEP) 0.2.0-draft.1 for morphir-dotnet hosts and guests: JSON-RPC 2.0 messages, Content-Length framing, the session lifecycle and the model transport. Work is tracked by #512 and add-mep-core. The roadmap is the Morphir extension model PRD, step 1.

Layers

Layer File What it does
Wire types Wire.fs Records and unions of the pinned contract, with parsed values (ProtocolVersion, SemanticVersion, Sha256Digest, RequestId). MepJson is generated from this file at build time by Morphir.Myriad.SystemTextJson. There is no reflection serializer.
Model transport ModelTransport.fs Tuple selection, the host check of a selection, envelope creation and admission. Pure functions.
Message codec Rpc.fs Classifies a JSON-RPC message by its members (JsonRpcMessage), keeps params raw, and writes messages. This is the only hand-written JSON.
Dispatcher Dispatcher.fs DispatchAsync(bytes, ct) returns the reply bytes, or none for a notification. A method table maps method names to typed handlers; a gate refuses a method before its handler runs.
Framing Framing.fs Content-Length frames on a Stream: header blocks up to 8192 bytes, bodies up to 64 MiB, checked before the body is read. A refused frame ends the connection.
Connection Connection.fs Reads frames, dispatches inbound requests concurrently, matches inbound responses to the pending-request table, and sends and receives $/cancelRequest.
Session Session.fs The pure lifecycle rules (Lifecycle.admit) and version negotiation, shared by hosts and guests.
Peers Peers.fs Guest (lifecycle methods, gate, extension methods) and HostSession (refuses to send what the guest must refuse).

The stream path (Connection) and the single-message path (Dispatcher.DispatchAsync) use the same dispatcher, so they give the same bytes. Starting a guest process is not in this project: a process host connects a HostSession to the child's streams.

A guest and a host in memory

This example is compiled by tests/Morphir.Mep.Tests/ReadmeTests.fs. Keep the two equal.

let runSession (claims: CapabilityClaimSet) (capabilities: ExtensionCapabilities) =
    task {
        let guest =
            Guest(
                { Claims = claims
                  Capabilities = capabilities
                  Methods = readOnlyDict [] }
            )

        let toGuest = Pipe()
        let toHost = Pipe()
        let guestRun = guest.RunAsync(toGuest.Reader.AsStream(), toHost.Writer.AsStream(), CancellationToken.None)

        let host =
            HostSession(
                toHost.Reader.AsStream(),
                toGuest.Writer.AsStream(),
                { Kind = PeerKind.Cli; Name = "morphir"; Version = "0.4.0" },
                null
            )

        let hostRun = host.RunAsync CancellationToken.None
        let! session = host.InitializeAsync CancellationToken.None
        let! ping = host.PingAsync CancellationToken.None
        let! _ = host.ShutdownAsync CancellationToken.None
        do! host.ExitAsync()
        let! guestEnd = guestRun
        toHost.Writer.Complete()
        let! _ = hostRun
        return session, ping, guestEnd
    }

Add a method

  1. Check that the pinned contract has the method and its params and result types. Do not add a method, member or error code that the pin does not have; raise an upstream issue.
  2. Write a failing wire test, then add the types to Wire.fs with the attributes that the contract's wire rules need. Add the type to the contract test (ContractTests.fs): a complete sample, and the members that the contract text lets a reader default.
  3. Add the method to Method if it is new, and its capability to Lifecycle.capability if the contract makes it depend on one (the guest replies -32013 without it).
  4. Register a handler in the guest's Methods with Handlers.request (params bind as one object through their codec; absent or mismatched params give -32602), and add a typed call to HostSession if hosts send it.
  5. Add the method to the AOT probe (tests/Morphir.Mep.AotProbe) when it changes what C# calls.

The pin

tests/Fixtures/Mep pins the upstream contract model (mep.ir.json), the transcripts and the model-transport corpus by commit and digest. Do not edit the fixtures. To update the pin:

  1. Copy the new files from finos/morphir at one commit, and record the commit and the SHA-256 digests in PROVENANCE.md.
  2. Run the tests. ContractTests fails for each renamed or added member, and the transcript and corpus tests fail for each changed behavior.
  3. Change the types and rules in the same pull request. A new MEP version moves every MEP part in morphir-dotnet together; drafts match only exactly.

Where a transcript and the contract text disagree, the tests follow the contract text. The legacy transcripts initialize with 0.1; the replays use 0.2.0-draft.1 instead.

C# callers

The project is trimmable and AOT-compatible, with F# nullness metadata. Parsed values have TryParse and Create; FrameRead has Match. tests/Morphir.Mep.AotProbe is a C# consumer that runs the full session; InteropTests compiles C# examples and checks the nullable-flow diagnostics.

Tests

dotnet run --project tests/Morphir.Mep.Tests -- --summary
./build.sh --target TestMepAot --configuration Release

The first command runs the wire, contract, JSON-RPC, connection, session and model-transport tests on in-memory streams. The second publishes the probe with Native AOT, refuses IL diagnostics other than the FSharp.Core summary baseline, and compares the native output with JIT byte for byte. Both run in PR CI.

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 (2)

Showing the top 2 NuGet packages that depend on Morphir.Mep:

Package Downloads
Morphir.Extensions

Morphir extension registry domain: parsed extension identities, capability claims and the extension catalog
Morphir.Compilation.Mep

The MEP 0.2.0-draft.1 frontend adapter: an IFrontend over a guest process that serves morphir.frontend.compileModel. Trim-safe and AOT-safe.

GitHub repositories

This package is not used by any popular GitHub repositories.

Version Downloads Last Updated
0.4.0-alpha.4 54 11/10/2026
0.4.0-alpha.3 61 11/9/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