Infer.NET: Bayesian Inference as Generated C# Code

The problem Infer.NET solves: inference code you can read

Most probabilistic programming tools ask you to describe a model in a domain-specific language and hand the inference algorithm to the runtime. Infer.NET takes a different position. The model is written in ordinary C# using the Infer.NET API, and a separate compiler project converts that description into inference code. The README states that the Compiler package "takes model descriptions written using the Infer.NET API and converts them into inference code." That generated code is a visible artifact, and the Compiler project also ships "utility methods for visualization of the generated code."

The audience follows from that design. If you are a .NET developer who needs a classifier, a recommender, or a topic model, and you want to see and potentially modify the message-passing code that does the work, the compiler is the point. If you want to write a model in a few lines of Python and never look underneath, the same compiler is overhead you are paying for nothing. The README lists classification, recommendation, and clustering as standard problems, with a Bayes Point Machine classifier, a Matchbox recommender, and a mixture of Gaussians tutorial as the concrete entry points.

How the compiler turns a C# model into inference code

The architecture in the repository separates three concerns. The model description lives in C# source that references the Infer.NET API. The Compiler project in src/Compiler reads that description and produces inference code. The runtime classes in Microsoft.ML.Probabilistic execute the result. The README describes the Compiler project as converting model descriptions into inference code, and the runtime package as containing "classes and methods needed to execute the inference code." Those are two different packages, and the split is deliberate: the compiler is a build-time dependency, the runtime is what ships.

A fourth package, Microsoft.ML.Probabilistic.Learners, sits above both and contains "complete machine learning applications including a classifier and a recommender system." That is the layer to reach for when you do not want to write message-passing code yourself. The repository also contains src/Csoft, described as "an experimental feature that allows to express probabilistic models in a subset of the C# language." The word experimental is the README's, and it should be read literally: Csoft models are tested through unit tests marked with a CsoftModel category trait, which suggests the feature is exercised by the test suite rather than presented as a supported front end.

There are wrappers for two other languages. src/FSharpWrapper "hides some of the generic constructs in the Infer.NET API allowing simpler calls to the Infer.NET API from standard F#." src/IronPythonWrapper contains a wrapper for calling Infer.NET from IronPython. Both indicate that the core API is generic-heavy enough that other .NET languages need a shim to use it comfortably.

Installing Infer.NET from NuGet

You do not need the repository to use the library. The README states that binaries are on nuget.org, that they are cross-platform, and that the core packages target .NET Standard 2.0. That target makes them usable from projects on .NET Framework 4.6.2 or .NET Core 3.1, per the README's reference to the .NET implementation support table. There are four maintained packages: Microsoft.ML.Probabilistic, Microsoft.ML.Probabilistic.Compiler, Microsoft.ML.Probabilistic.Learners, and Microsoft.ML.Probabilistic.Visualizers.Windows. The last one is described as a .NET Framework and Windows specific set of visualization tools, so it is the odd package out on a Linux or macOS machine.

The README gives the command-line route for adding references to an existing project:

dotnet add package Microsoft.ML.Probabilistic dotnet add package Microsoft.ML.Probabilistic.Compiler dotnet add package Microsoft.ML.Probabilistic.Learners

Visual Studio users get the equivalent through Project -> Manage NuGet packages. If you want to build from source instead, the README points at Infer.sln in the repository root, which contains all components, unit tests, and sample programs. The repository is organized under src/, with Compiler, Csoft, Examples, FSharpWrapper, IronPythonWrapper, and Learners as the main folders. The Examples folder is where the runnable material lives: ClickThroughModel for search click sequences, ClinicalTrial with an interactive interface, InferNET101 for the basics, ImageClassifier, LDA for topic modeling, MontyHall, and MotifFinder for nucleotide motif discovery.

Where the compile-then-run model costs you

The compiler is a build step, and build steps have failure modes. A model that compiles is not automatically a model that infers well. The README does not describe what happens when the compiler cannot derive a message-passing schedule for a given model, and it does not describe error reporting from the Compiler project. That gap matters because the generated code is the product: if the compiler silently falls back to a slower approximation, the user may not notice until results look wrong. I cannot confirm from the supplied material whether such diagnostics exist.

The LDA example is the honest signal about scaling. The README says its implementations "pay special attention to scalability with respect to vocabulary size, and with respect to the number of documents" and that they "provide good examples for how to scale Infer.NET models in general." The framing implies that scaling is not automatic and that model authors are expected to think about it. A topic model over a large vocabulary is exactly the case where a naive model description produces generated code that is too slow or too large.

There is also a language constraint. Csoft, the feature that would let you write models in a C# subset rather than the Infer.NET API, is labeled experimental in the README. If your plan depends on Csoft, you are building on a feature the project itself does not present as settled. The two language wrappers carry a similar message: the core API needs an F# shim and an IronPython shim to be pleasant, which tells you something about how the generics feel from outside C#.

Infer.NET against Stan and PyMC

The obvious alternative is Stan or PyMC, which take a model written in a dedicated language or in Python and run inference without exposing a compiler step to the user. The difference is not just syntax. In Stan and PyMC, the inference algorithm is chosen by the user from a menu and the model is data. In Infer.NET, the compiler derives the inference code from the model description, and that code becomes an artifact you can read and, per the README, visualize. If your problem is a standard one, the Learners package gives you a classifier and a recommender without writing a model at all, which is closer to the scikit-learn experience than to Stan.

The trade is control against reach. A Stan user can install a toolchain and fit a model in an afternoon. An Infer.NET user needs a .NET project, a compiler package, and a model written against a generic API, in exchange for generated code that can be inspected. For a team already shipping .NET services, that exchange can be favorable. For a data science team working in Python notebooks, it means maintaining a second toolchain for no gain in modeling expressiveness that the README demonstrates.

Maintenance, licensing, and what the repository tells you

Infer.NET is MIT licensed, which permits commercial use and modification with the usual requirement to preserve the copyright notice. Nothing in the supplied material suggests a dual-license arrangement or a contributor licence agreement that would change that, but the licence text itself is the authority, not this article.

The project is not archived, and the repository shows a last push in July 2026. The README does not list release notes, and no recent releases were retrieved, so I cannot describe a release cadence or a version history from the material at hand. What the repository does show is a maintenance surface: a Visual Studio solution with components, unit tests, and samples; nightly build definitions for Windows, Linux, and macOS; and four NuGet packages that all carry the Microsoft.ML.Probabilistic prefix. Upgrading means tracking those four packages together, and the Visualizers.Windows package ties part of the tooling to Windows and .NET Framework. The .NET Standard 2.0 target on the core packages is a floor, not a ceiling, and the README does not state which newer .NET versions are tested.

Who should pick this up

The README names the domains where Infer.NET has been used: information retrieval, bioinformatics, epidemiology, and vision. The repository gives you the artifacts to judge those claims yourself rather than taking them on faith. ClickThroughModel, MotifFinder, and ClinicalTrial are each a complete example in a named domain, and InferNET101 is the entry point for the API itself. Start there. If you can read the generated code for one of those examples and understand what the compiler produced, the framework will make sense to you. If the generated code is opaque, the compiler is working against you rather than for you, and a tool that hides its inference algorithm would serve you better.

Editorial conclusion

Adopt Infer.NET if your team already writes C# and you need to inspect or edit the inference algorithm, not just the model. Do not adopt it if you want a declarative model file and a one-line training call, or if you need a GUI-driven workflow. Before committing, run the LDA example in src/Examples to see how the compiler handles a model with large vocabulary, and check that the generated code is something your team can read.

Official sources

1. dotnet/infer on GitHub
2. Issues
3. License: MIT
4. Project website
5. README