Microsoft PROSE: a program synthesis SDK kept alive as samples after versioning stopped

New SDK versions stopped in October 2025, and that changes what this repo is

The first line of the README is a notice rather than a description, and it should shape any decision about this repository.

As of October 14, 2025, we have stopped releasing new versions of the PROSE SDK.

That single fact reframes everything else in the project. What you are looking at is not the active distribution channel for a synthesis framework, it is the public residue of one. The SDK itself lives elsewhere, at the internal Microsoft repository that the contributing section names as the source of truth, and what was published here was the samples, release notes and miscellaneous related projects.

The practical consequence for an adopter is that there is no upgrade path to plan for and no new features arriving. If you want to know what PROSE could do, this repository answers that question well. If you want a dependency that will still receive engine fixes, it does not.

There is a second, more unusual warning, and it is in the contributing section rather than at the top. The source of truth for all the information in this repository is actually an internal Microsoft repository, and any changes made here are at risk of being overwritten by future public releases from the PROSE team.

So contributions are invited, issues are welcome, and yet the public copy is not authoritative. The contributing section handles this gracefully: if you detect issues with any of the samples, open an issue and someone from the PROSE team will work with you to see that the problem is addressed. The flow of fixes runs through the team rather than through pull requests into this tree.

The last push was on 2026-10-14, so the repository is not abandoned in the sense of being frozen, and it is not archived. What it is, is a published snapshot that Microsoft still touches.

The primary language is C#, the homepage is microsoft.github.io/prose/, and the repository has no GitHub releases of its own.

Two kinds of sample, and they teach different things

The samples split into two categories, and the split is the fastest way to understand what PROSE expects of you.

The first category is samples for using existing PROSE DSL APIs to accomplish tasks, and they live in the api-samples directory with a solution file at api-samples/api-samples.sln. These are consumers of an existing domain specific language. Something is already modelled, and you write code that calls the API.

The second category is samples for creating program synthesis solutions using the PROSE SDK by authoring a DSL, and they live in dsl-samples. This is the harder half. Three entries are named: a DSL authoring tutorial at dsl-samples/tutorial, the ProseSample solution at dsl-samples/ProseSample/ProseSample.sln, and a DSL for merge conflict resolution at dsl-samples/MergeConflictsResolution/MergeConflictsResolution.sln.

The difference in effort between those two halves is the substance of the project. Using an existing DSL API is ordinary library consumption. Authoring a DSL means deciding what the domain is, what the operators are, how the search space is pruned, and how an example maps onto a candidate program. The tutorial is where that is taught, and the merge conflict resolution sample is where it is shown on a problem people actually recognise.

Merge conflict resolution is a particularly good demonstration because the input-output examples have an obvious shape. Two conflicting versions of a file in, a merged file out. The search space is large enough to need real pruning, and the domain is small enough to be described in a DSL. If you want to judge whether example-based synthesis fits your own problem, that sample answers more usefully than a toy one would.

The repository also carries a misc/ directory and a release-notes/ directory, and the top level has .config/, Directory.Build.props, Directory.Build.targets and Directory.Packages.props. Those three Directory files are the modern MSBuild arrangement for central package version management and shared build settings, and they are the clearest evidence that this is a set of real, buildable .NET solutions rather than snippets.

Central package management is how these solutions stay buildable

The build files at the repository root are worth a look even if you never write a line of synthesis code, because they show how a multi-solution repository is kept consistent.

Directory.Packages.props is the central package version management file. Under this model, individual projects do not each carry a version number for the packages they reference. Instead, the versions live in one place and the projects refer to them. For a repository holding several solutions that all need the same PROSE packages at the same versions, that is the difference between one upgrade and several.

Directory.Build.props holds properties that apply to every project in the tree, and Directory.Build.targets holds targets that likewise apply to every project. Those are where shared settings such as language version, or a common referenced package, are set once rather than repeated in each csproj.

There is a .config/ directory at the top level as well. In a .NET repository that conventionally holds the dotnet tool manifest, which pins the versions of local tools so that every developer and every build agent has the same ones.

The consequence for someone picking this up is practical. You open the solution in Visual Studio, the central package management file resolves the PROSE package versions for you, and the samples build without you having to hunt for compatible version numbers. That matters most here, because the SDK stopped receiving new versions: the versions that the samples were written against are the versions that exist, and the pins in Directory.Packages.props are what make that reproducible.

It is also a limit worth naming. With no new SDK releases, the pinned versions are the only versions there will be, so any issue you hit with a PROSE package version will not be fixed upstream. The samples still work against what they were written for; the question of what happens when you take them further is on you.

The repository carries SECURITY.md and SUPPORT.md at the root alongside CODE_OF_CONDUCT.md, and it has adopted the Microsoft Open Source Code of Conduct.

The licence is not a standard open source grant, and that is the first thing to check

The licence is the item most likely to surprise a reader who arrived expecting an ordinary Microsoft open source project.

The repository is recorded as Other, a custom licence that GitHub cannot classify, with the LICENSE file at the root as the authority. There is no MIT, no Apache 2.0 and no SPDX identifier to look up.

That is not automatically a problem. Many large organisations publish their internal licences for open source projects, and the pattern is common enough that a custom licence is a flag to read the file rather than a reason to walk away. But it does mean two things.

First, you cannot answer a compliance question from the repository metadata alone. A dependency scanner will report an unrecognised licence, and a policy that allows only permissive, well known licences will need a human decision rather than an automated pass.

Second, and more importantly, a custom licence is a bespoke grant and it may contain terms that MIT and Apache 2.0 do not have: attribution clauses, redistribution conditions, a trademark carve-out, a patent clause or a no-endorsement rule. Whether any of those apply to your use is a question for whoever reads licences in your organisation, not for this article.

The same caution applies to the samples themselves. The samples are the substance of this repository and they are covered by whatever the LICENSE file grants. Reading that file is the first concrete step for anyone considering building on these samples, and it should happen before the build, not after.

The open source code of conduct and the SECURITY.md file show the governance machinery is in place, which is a reasonable signal about how the project treats itself, but a code of conduct is not a licence and a security policy is not a grant.

Where PROSE is the wrong tool

The first wrong-tool case is a team that needs a supported, evolving synthesis engine. The SDK stopped releasing new versions on 2025-10-14 and the repository itself warns that its contents can be overwritten by future public releases from the PROSE team. Adopting a stopped product as a dependency is a decision with a known expiry, and the artefacts here are the right thing to study and the wrong thing to build on without a plan for taking ownership.

The second case is a problem where examples are expensive. The whole approach is driven by input and output pairs. If you cannot produce examples, or if producing them costs more than writing the transformation, the technique inverts the economics. Merge conflict resolution works because the merged output is a natural thing to want and the examples are cheap. A transformation with a hundred bespoke cases is a different problem.

The third case is a project that does not want to author a DSL. The api-samples path assumes an existing domain specific language is available to call. If the domain language for your problem does not exist and you are not willing to write one, the sample set offers no shortcut, because the synthesis work in PROSE sits above a DSL you have already designed.

The fourth case is a team that needs a supported product with a service agreement. There is a Discord-style community route and a support file, but a research SDK from a large organisation that has stopped versioning it is not a vendor relationship.

What you do get is a complete worked example of the authoring model in C#, including one problem the domain is recognisable, plus the build plumbing that makes several solutions share pinned package versions. For learning the technique or for judging whether example-based synthesis fits your domain, that is genuinely useful, and it is available today with a Visual Studio install and no network dependency on a discontinued feed.

Editorial conclusion

This repository suits a developer who wants to see how example-based program synthesis is built in C#, because the DSL authoring tutorial and the merge conflict resolution sample show the authoring model end to end and can be opened in Visual Studio today. It does not suit a team planning to build a production service on the SDK, since Microsoft stopped releasing new versions on 2025-10-14 and the licence is a custom Microsoft one rather than a standard open source grant. Before adopting, open api-samples/api-samples.sln and the dsl-samples tutorial side by side to see which model fits, and read the contributing section, which warns that changes here can be overwritten by future public releases from the PROSE team.

Frequently asked questions

Official sources

1. Issues
2. microsoft/prose on GitHub
3. Project website
4. README