YoloDotNet runs YOLO models in C# without a Python runtime

ONNX Runtime and SkiaSharp instead of OpenCV and Python

YoloDotNet is built on .NET 8, ONNX Runtime and SkiaSharp, and the README is explicit that it avoids heavy computer vision frameworks such as OpenCV. There is no Python runtime, no hidden preprocessing and no implicit behavior, which is the design decision that separates it from the usual path of shipping a Python inference service next to a .NET application.

Inference is delegated to ONNX Runtime, and the hardware path is chosen by the caller rather than negotiated at runtime. The execution providers are separate packages for CPU, CUDA, OpenVINO, CoreML and DirectML, so a deployment on Windows with an NVIDIA GPU, a Linux box with a discrete accelerator, and a Mac with Apple silicon are all the same code with a different provider object. The CUDA package includes optional TensorRT acceleration, and no separate TensorRT package is required.

The model families the library reads span YOLOv5u through YOLOv26, YOLO-World, YOLO-E and RT-DETR. That range is wide enough that the input contract matters, which is why the model export step below is not optional. What the library does not do is train, convert or host anything on its own. It is the inference layer of a pipeline, and the rest of the pipeline is your responsibility.

Adding the package and choosing exactly one execution provider

Installation is two dotnet commands, and the README insists on a detail that is easy to get wrong: exactly one execution provider. The core package goes in first.

dotnet add package YoloDotNet

Then you add one provider. The CPU package is described as the recommended starting point, and the hardware-accelerated options are listed separately.

# CPU (recommended starting point)
dotnet add package YoloDotNet.ExecutionProvider.Cpu

# Hardware-accelerated execution (choose one)
dotnet add package YoloDotNet.ExecutionProvider.Cuda
dotnet add package YoloDotNet.ExecutionProvider.OpenVino
dotnet add package YoloDotNet.ExecutionProvider.CoreML
dotnet add package YoloDotNet.ExecutionProvider.DirectML

Because each provider ships as its own package, an application that accidentally references two of them has a runtime conflict that the build will not catch for you. The README also warns that the CUDA provider carries optional TensorRT acceleration with no extra package, which matters if you were expecting a separate TensorRT install step.

The repository ships runnable examples under the Demo directory, with one project per task type: ObjectDetectionDemo, SegmentationDemo, PoseEstimationDemo, OBBDetectionDemo, ClassificationDemo, BatchDemo, VideoStreamDemo, WebcamDemo, TensorRTDemo, DockerDemo and YoloE_SegmentationDemo. Those projects are the fastest way to see a working configuration for the provider you plan to ship.

Exporting the ONNX model with the opset the family expects

YoloDotNet consumes ONNX files, and the README specifies the opset to use at export time. YOLOv26 models are exported with opset=18, and YOLOv5u through YOLOv12 are exported with opset=17. The stated reason is compatibility and performance with ONNX Runtime.

The Ultralytics CLI examples given are:

yolo export model=yolov8n.pt format=onnx opset=17
yolo export model=yolo26n.pt format=onnx opset=18

A mismatched opset is the kind of mistake that shows up as a load failure or as silently degraded detections rather than as a compile error, so treat the opset as part of the artifact you pin. The README points to the Ultralytics export documentation for the general procedure, which means the export step lives outside this project and inside a tool that has its own licensing, which the README also flags.

Nothing in the repository converts a .pt checkpoint for you. The library starts at the ONNX file, so the model you hand it has already been through the export path above.

Preprocessing, not the model, decides whether results are right

The README makes a claim worth repeating precisely: YOLO inference accuracy is not automatic. Preprocessing settings such as image resize mode, sampling method and the confidence and IoU thresholds must match how the model was trained, and the README says these settings directly control the accuracy and performance tradeoff and should be treated as part of the model itself.

This is the part that trips up newcomers. A working inference that returns plausible boxes is not evidence that the configuration is right, because a resize mode that differs from training shifts the effective input geometry and can quietly cost you detections. The repository handles the explanation in a separate document, AccuracyAndConfiguration.md, and the README instructs readers to consult it before tuning models or comparing results.

The IoU parameter has a task specific wrinkle that the code sample comments call out. IoU is used for NMS-based models, while for YOLOv10 and YOLOv26 it is ignored because post-processing is handled internally by the model. So the same confidence and IoU pair you reuse across tasks is not always doing the same thing, and a comparison between two model families that uses a single shared parameter set is not a clean comparison.

The v4.2 helper methods turn raw results into exportable data

Version 4.2 is where the library stops being only an inference call and starts producing artifacts other tools can consume. Results can now be converted to JSON with ToJson() and written straight to a file with SaveJson(), and the same results can be emitted as YOLO-formatted annotations with ToYoloFormat() and SaveYoloFormat(), the format used as training data.

That second pair is the interesting one for a machine learning team. Saving detections and segmentations back in YOLO annotation format closes the loop between a deployed model and a later fine-tuning round, without a Python script in the middle. Segmentation output also gained GetContourPoints() for pulling ordered contour points out of masked objects, and an option to draw edges on segmented objects for visual clarity.

The same release added Region of Interest support, so inference can run only on selected areas of an image or a video stream, with surveillance and monitoring zones given as the motivating cases. Running inference on a crop rather than the full frame is the single cheapest way to cut per-frame cost in a live pipeline, and the release notes place ROI in the same version as the export helpers. The full history is kept in CHANGELOG.md, and the repository publishes no GitHub releases, so that file is the version record.

The library is MIT, the model weights are usually not

YoloDotNet itself is MIT licensed, with the LICENSE.txt file in the repository root. The README carries a separate and more consequential warning for the models: most Ultralytics YOLO models are AGPL-3.0 licensed or require a commercial license for commercial use, and the person using the library is responsible for ensuring that their use of any model complies with its license.

So the two licenses travel on different objects. The MIT terms cover the code you compile, while the checkpoint you load carries whatever terms the model publisher set. Shipping a service built on an AGPL-3.0 checkpoint without reviewing those terms is a decision the library cannot make for you, and the README is careful to point at the Ultralytics licensing page rather than pretending the question is settled. Whether any particular combination satisfies your compliance requirements is a question for whoever owns that in your organization.

For maintenance, the picture is simple: the repository is not archived and the last push was on 2026-10-18, so the code is moving quickly. The cost of that speed is that you should track CHANGELOG.md yourself, because there are no tagged releases to diff against.

Where YoloDotNet is the wrong tool

Three cases come to mind from the README itself. First, if you need to train or fine-tune, this library is out of scope. It consumes exported ONNX files, and the training path belongs to the Ultralytics tooling that the export step already depends on. Second, if your existing system is a Python service that already loads ONNX models successfully, replacing it with .NET inference trades a working pipeline for a port, and the accuracy configuration notes give you a fresh source of subtle mismatches to chase.

Third, there is the model family question. The supported set runs from YOLOv5u through YOLOv26, YOLO-World, YOLO-E and RT-DETR, and the opset requirement differs between the older families and YOLOv26. A custom or very recent architecture outside that list has no documented path into this library.

One more constraint is worth planning around: the library deliberately leaves no hidden preprocessing, which is a virtue for predictability and a burden for you. You are expected to know how the model was trained and to configure resize mode, sampling method and thresholds to match. The README treats the AccuracyAndConfiguration.md document as mandatory reading before tuning or comparing results, and a team that skips it will spend days chasing accuracy regressions that live in configuration rather than in the model.

Editorial conclusion

Adopt YoloDotNet when your team already ships .NET services or desktop apps, needs YOLO inference without a Python sidecar, and can supply a properly exported ONNX checkpoint with matching preprocessing settings. Do not adopt it to train models, to serve models you do not hold the rights to, or as a drop-in for a Python pipeline that already has a working export. Before writing the first line of integration code, confirm the opset your model family requires (17 for YOLOv5u through YOLOv12, 18 for YOLOv26), read AccuracyAndConfiguration.md so the resize mode and sampling method match the training setup, and check the license of the checkpoint itself, since the MIT license of the library does not touch the model weights.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. NickSwardh/YoloDotNet on GitHub
4. README