dotnet/machinelearning-samples: What the Official ML.NET Sample Repo Actually Contains

The gap between ML.NET documentation and a first working pipeline

ML.NET is described in the README as a cross-platform open source machine learning framework that makes machine learning accessible to .NET developers. That sentence sets the audience: people who already write C# or F# and want a model inside an existing application, not data scientists looking for a notebook environment. The problem this repository addresses is narrower than the framework's. Documentation tells you which trainer exists and what its arguments are; it does not always show the sequence of loading data, defining a schema, choosing a trainer, training, evaluating and saving a model as one file you can run. The samples are that sequence, written out. The README splits them into two types: Getting Started samples, described as ML.NET code focused samples for each ML task or area, usually implemented as simple console apps, and End-End apps, described as end-user sample web and desktop apps infused with Machine Learning models. That distinction matters when you are choosing where to look. If you want to understand the API, read a console sample. If you want to see a model wired into an application's request path, read an end-to-end app.

How the README table maps machine learning tasks to directories

The table is organised by task, then by scenario. Binary classification covers sentiment analysis, spam detection, credit card fraud detection and heart disease prediction. Multi-class classification covers GitHub issue labelling, iris flowers and MNIST handwriting. Recommendation splits into matrix factorisation for product and movie recommendation plus field aware factorization machines for a movie recommender end-to-end app. Regression covers taxi fare prediction, sales forecasting and bike sharing demand. Time series forecasting has a single entry, the sales forecasting end-to-end app, which also appears under regression. Anomaly detection begins with sales spike detection. Each cell links to a path such as samples/csharp/getting-started/BinaryClassification_SentimentAnalysis or samples/csharp/end-to-end-apps/MulticlassClassification-GitHubLabeler. The directory naming repeats the task and the scenario, which makes the layout predictable once you have read the table. Coverage is uneven in a way the table makes visible: heart disease prediction lists C# only, MNIST lists C# only, and the field aware factorization machines recommender lists C# only, while sentiment analysis, spam detection, credit card fraud, iris, taxi fare and bike sharing demand each list both C# and F#. If you work in F#, check the cell before you plan around a sample.

What the getting-started samples assume about your data

The getting-started samples are console applications, and that choice carries assumptions worth naming. A console app has no hosting model, no dependency injection container and no configuration system, so the sample can present the ML.NET pipeline without the scaffolding a web application would add. That is useful for reading, and misleading for porting. When you move the same code into an ASP.NET service, you have to decide where the model file lives, whether it is loaded once at startup or per request, and how the input schema is validated before it reaches the prediction engine. None of those questions are answered by a console sample because they do not arise in one. The repository does not claim otherwise. The README's own framing, code focused samples for each ML task or area, tells you the intent is to isolate the machine learning code rather than to demonstrate application architecture. Treat the console samples as reference material for the pipeline and the end-to-end apps as reference material for the wiring, and do not expect either to cover the other.

Getting a sample running and the commands the material does not give

The README does not include build or run commands. It links to sample directories and to the ML.NET homepage at https://dot.net/ml, and that is the extent of the setup guidance in the supplied material. What can be stated from the repository layout is the shape of the workflow: navigate to a sample directory under samples/csharp or samples/fsharp, then build and run the project inside it with the .NET SDK. The exact project file names, target frameworks and package versions are not in the material, so they have to be read from the sample directory itself. This is a real friction point rather than a stylistic complaint. A reader arriving from the README table gets a path and nothing else. The two release notes that are present both concern deep learning image classification with ML.NET and TensorFlow, dated June and August 2020, plus an April 2020 note about training an image classification model in Azure with ML.NET Model Builder. Those notes describe a specific scenario, not repository-wide setup instructions, and they are the most recent releases listed.

The staleness question and why the sample repo is not the framework repo

The README draws an explicit boundary: issues about the ML.NET framework belong in the Machine Learning repository, and issues should be created here only for problems with the samples. That division is sensible, and it also tells you what this repository is not. It is not where the API is defined, versioned or supported. The newest release in the material is from August 2020. A repository can receive commits without cutting releases, and the last push date of 2026-09-03 shows activity of some kind, but the release list is the only versioning signal available here, and it points at samples built against an older ML.NET surface. The practical consequence is that a sample may compile against a pinned package version in its own project file while the pipeline code it demonstrates has since changed in the framework. This is not a reason to avoid the repository. It is a reason to read the sample's project file before copying its C# into your application, rather than copying the C# alone.

Where ML.NET Model Builder is the better entry point

The most direct alternative for a .NET developer who wants a model without writing pipeline code is ML.NET Model Builder, which appears in this repository's own release notes as the subject of an April 2020 entry about training an image classification model in Azure. The difference in approach is the level at which you work. The samples in this repository expose the pipeline: you see the data loading, the trainer selection, the evaluation metrics and the model save, and you are expected to edit that code. Model Builder generates a model from a guided flow and hands you a consumed model plus generated code, which means fewer decisions and less visibility into them. Choose the samples when you need to understand or modify the training step, for instance to change the trainer, adjust the data split or add a custom mapping. Choose Model Builder when the task matches a supported scenario and you want the model, not the pipeline. Neither replaces the other, and a team that starts with Model Builder and later needs to tune the trainer will end up reading samples like these anyway.

Maintenance, licensing and what the MIT terms cover here

The repository is licensed under MIT, which is permissive and permits reuse and modification with the licence and copyright notice retained. That covers the sample code in this repository. It does not cover ML.NET itself, which is a separate project with its own licensing, and it does not cover any dataset a sample downloads, since those come from elsewhere and carry their own terms. The material does not enumerate those datasets or their licences, so that check has to happen per sample. On maintenance cost, the honest reading of the supplied material is that the repository is a catalogue rather than a dependency. You do not take a version of it and upgrade it; you copy a sample, adapt it, and own the result. The cost is therefore front-loaded into the adaptation, and the ongoing cost is whatever you spend keeping your adapted pipeline current with the ML.NET version you target. The release list, with its newest entry in 2020, is the signal that the samples are not tracking the framework release cadence closely, so budget for that gap when you pick which sample to start from.

Editorial conclusion

Adopt this repository if you are starting an ML.NET project and want a runnable reference for a specific task, such as binary classification, matrix factorisation recommendation or taxi fare regression, before writing your own pipeline. Do not adopt it if you need a maintained library, a supported product, or a sample that tracks the current ML.NET API surface; the newest release note in the material dates from August 2020, so verify API compatibility against the ML.NET version you have installed before copying any code. The first thing to check is the README table entry for your task and language, because the C# and F# coverage is not uniform.

Official sources

1. dotnet/machinelearning-samples on GitHub
2. License: MIT
3. Project website
4. README
5. Releases