# ML.NET: machine learning inside a .NET application

> ML.NET is Microsoft's cross-platform machine learning framework for .NET, distributed as NuGet packages. It fits teams that want to train and score models in C# without standing up a Python service, and it is the wrong tool when you need the newest research architectures on day one.

**dotnet/machinelearning** — ML.NET is an open source and cross-platform machine learning framework for .NET.

- Repository: https://github.com/dotnet/machinelearning
- Website: https://dot.net/ml
- Stars: 9,357 · Forks: 1,949
- Language: C#
- License: MIT
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/dotnet-machinelearning

## The problem ML.NET solves for .NET teams

Most machine learning tooling assumes Python. That assumption creates a seam in a .NET codebase: the model is trained in one language, exported, and then called across a process boundary or a network hop from the application that actually needs the prediction. ML.NET closes that seam. The README states that developers can build, train, deploy and consume custom models in their .NET applications "without requiring prior expertise in developing machine learning models or experience with other programming languages like Python or R".

The audience is therefore narrow and identifiable: C# developers who need classification, forecasting or anomaly detection inside an existing .NET service, and who would rather not operate a second runtime for it. The framework also loads data from files and databases and applies transformations before training, so a team can keep an existing ETL or data access layer and feed it into the trainer. If your team already writes Python and your infrastructure already runs Python, the pitch is much weaker.

## How a model is built and consumed in ML.NET

The README describes a pipeline shape rather than a single call: load data, transform it, then train. Data loading and transformations come from the framework itself, and the algorithms ship with it. The output of training is a model object that the same application can use to score new rows, which is why the framework is described as letting developers deploy and consume models in their own applications.

The important architectural detail is the boundary around what ML.NET does not implement itself. The README says you can consume both TensorFlow and ONNX models within ML.NET, which it frames as making the framework more extensible and expanding the supported scenarios. In practice that means two different jobs can be handled in one codebase: models trained with ML.NET trainers, and models trained elsewhere and imported. The README does not describe a serving layer, a model registry, or a scheduling component. Those are not part of this repository, and a team expecting an end-to-end platform will be looking in the wrong place.

## Installing the Microsoft.ML package and training a first model

The README gives the prerequisite plainly: install .NET Core 2.1 or later. It also notes that ML.NET works on .NET Framework 4.6.1 or later, with 4.7.2 or later recommended. Once you have an application, the package comes from NuGet. From the .NET Core CLI:

```bash
dotnet add package Microsoft.ML
```

If you prefer the Package Manager console inside Visual Studio, the README gives the equivalent form:

```bash
Install-Package Microsoft.ML
```

The README also mentions that you can add the Microsoft.ML package from Visual Studio's NuGet package manager or via Paket, and that daily NuGet builds are published to an Azure DevOps feed at https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet-libraries/nuget/v3/index.json. For a first real use, the README does not inline a training sample. It points instead to the ML.NET Getting Started tutorial, the documentation and tutorials site, the API reference, and the separate dotnet/machinelearning-samples repository, which the README suggests cloning and running. That is the honest starting path: the repository is the framework, not the walkthrough. Expect to leave this repo to write your first pipeline.

## Platform limits, 32-bit gaps and the TensorFlow boundary

The support matrix is where a project plan can quietly break. ML.NET runs on Windows, Linux and macOS using .NET Core, and on Windows using .NET Framework. It also runs on ARM64, Apple M1 and Blazor Web Assembly, but the README attaches a caveat and links to a platform limitations document rather than listing the caveats inline. That link is the first thing to read if your deployment target is not a plain x64 Linux or Windows host.

The sharper constraint is 32-bit. 64-bit is supported on all platforms, but 32-bit is supported on Windows only, and specifically not for TensorFlow and LightGBM related functionality. A 32-bit Windows service that needs either of those two paths is out of scope, and no amount of configuration will change that. The README does not document a workaround. Note also that the repository contains a separate README-oneDAL.md, which suggests an additional acceleration path with its own documentation outside the main README; the main README does not explain it.

## Where ML.NET is the wrong choice

ML.NET is a framework for shipping models inside .NET applications, and it is honest about that scope. If your work is exploratory, if you need to iterate on architectures in a notebook, or if your team's existing tooling and hiring are Python-shaped, adopting ML.NET adds a language boundary rather than removing one. The README's own framing, that no prior ML expertise or other language experience is required, is a statement about the target user, not a claim that the framework replaces a research workflow.

The second wrong-tool case is model novelty. The README lists the supported scenario families as classification, forecasting and anomaly detection, and routes anything beyond that through TensorFlow or ONNX imports. If a model architecture is only available in a Python library and has no ONNX export path, ML.NET cannot host it. There is no statement in the README about a conversion service or a fallback. The third case is scale-out serving: nothing in the README describes distributed training or a model server, so a team that needs those should treat ML.NET as the training and in-process scoring layer and build the rest themselves.

## ML.NET against the Python stack and against imported ONNX models

The real alternative for most teams is the Python ecosystem: train with scikit-learn or a deep learning framework, then expose the model over HTTP or export it. The difference is not the algorithms, it is where the boundary sits. In the Python approach the boundary is a process or a network call, and the model can be updated without redeploying the .NET application. In ML.NET the boundary can disappear entirely: the model is an object in the same process as your business logic, which removes serialization and latency questions but couples model updates to application deployments.

The second alternative is already inside ML.NET's own story: train elsewhere, export to ONNX, and consume the ONNX model through ML.NET. That keeps the .NET hosting model while letting you pick any training stack that can emit ONNX. The README presents TensorFlow and ONNX consumption as the extensibility route, so this is a supported path rather than a workaround. The trade-off is that you now maintain two toolchains and a conversion step, and a failed or lossy export becomes a build-time problem you own.

## Release cadence, licence and the cost of upgrading

The repository is not archived, and the last push was on 2026-09-10. Recent releases listed are v6.0.0-preview1 on 2026-03-12, v5.0.0 on 2025-11-11, and v4.0.3 on 2025-10-28. The pattern worth noticing is that a preview of the next major line has been sitting alongside a stable 5.0.0 for months. If you pin Microsoft.ML in production, pin the stable version and treat the preview as a separate evaluation track; the README does not document a rollback procedure, and the release notes directory is where change detail lives.

The licence is MIT, which is permissive and places few obligations on how you redistribute the framework inside a product. This is a description of the licence identifier in the repository, not legal advice; if you ship a modified copy or bundle the packages, have your own counsel read the LICENSE file. Third-party components are listed separately in THIRD-PARTY-NOTICES.TXT, and the presence of that file means the MIT label on the repository does not by itself describe every dependency you will pull in. The upgrade cost is mostly the .NET version treadmill: the README's floor is .NET Core 2.1, but the CI badges reference net6.0 and net461 jobs, so the versions actually built and tested in this repository are newer than the documented minimum.

## Conclusion

Adopt ML.NET when your application already runs on .NET and the model has to live in the same process as the business logic, for example a console app or service that scores rows loaded from a file. Do not adopt it as a general research environment: the README points to TensorFlow and ONNX for models built elsewhere, and there is no Python-style notebook workflow in this repository. Before committing, verify three things: that your target runtime is covered by the platform limitations document, that the package version you pin exists on NuGet, and that the algorithm you need is exposed in the API reference rather than only reachable through a TensorFlow or ONNX import.

## FAQ

### How do I install ML.NET?

Install .NET Core 2.1 or later, then add the NuGet package from the .NET Core CLI with dotnet add package Microsoft.ML, or use Install-Package Microsoft.ML from the Package Manager console. The README also notes the package can be added through Visual Studio's NuGet package manager or via Paket.

### How do I use a machine learning model in ML.NET?

The README describes loading data from files and databases, applying transformations, and training a model that the same .NET application then consumes. For a guided first model it points to the ML.NET Getting Started tutorial and the separate dotnet/machinelearning-samples repository rather than inlining a sample.

### How do I use machine learning in Python instead of ML.NET?

ML.NET is not a Python library; the README positions it for .NET developers who do not need Python or R experience. If your training happens in Python, the README's stated path is to consume the resulting TensorFlow or ONNX model from within ML.NET.

### How do I use machine learning for data analysis in ML.NET?

The README states that ML.NET provides data loading from files and databases and enables data transformations before training. It lists classification, forecasting and anomaly detection as the scenario families, and points to the documentation and tutorials for the workflow details.

## Sources

- [dotnet/machinelearning on GitHub](https://github.com/dotnet/machinelearning)
- [License: MIT](https://github.com/dotnet/machinelearning/blob/main/LICENSE)
- [Project website](https://dot.net/ml)
- [README](https://github.com/dotnet/machinelearning/blob/main/README.md)
- [Releases](https://github.com/dotnet/machinelearning/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/dotnet-machinelearning