🚀 Blazing-fast, production-ready YOLO inference for .NET
YoloDotNet is a fully featured C# library for real-time computer vision using YOLOv5u–v12, YOLO-World, and YOLO-E models.
Built on .NET 8 and ONNX Runtime, it delivers high-performance, predictable inference on Windows, Linux, and macOS — with explicit control over execution, memory, and preprocessing.
No Python. No magic. Just fast, deterministic YOLO — done properly for .NET.
YoloDotNet is designed for developers who need:
- ✅ Pure .NET — no Python runtime, no scripts
- ✅ Real performance — CPU, CUDA / TensorRT, OpenVINO, CoreML
- ✅ Explicit configuration — predictable accuracy and memory usage
- ✅ Production readiness — engine caching, long-running stability
- ✅ Multiple vision tasks — detection, OBB, segmentation, pose, classification
YoloDotNet is ideal for developers building desktop apps, backend services, or real-time vision pipelines in .NET who need predictable performance and explicit control.
- Modular execution providers (CPU, CUDA/TensorRT, OpenVINO, CoreML)
- New OpenVINO and CoreML providers
- Cleaner dependency graph
- Improved GPU behavior and predictability
- Grayscale ONNX model support
📖 Full release history: CHANGELOG.md
dotnet add package YoloDotNet# CPU (recommended starting point)
dotnet add package YoloDotNet.ExecutionProvider.Cpu
# Optional GPU acceleration
dotnet add package YoloDotNet.ExecutionProvider.Cuda
dotnet add package YoloDotNet.ExecutionProvider.OpenVino
dotnet add package YoloDotNet.ExecutionProvider.CoreML💡 Note: The CUDA execution provider includes optional TensorRT acceleration. No separate TensorRT package is required.
using SkiaSharp;
using YoloDotNet;
using YoloDotNet.ExecutionProvider.Cpu;
using var yolo = new Yolo(new YoloOptions
{
ExecutionProvider = new CpuExecutionProvider("model.onnx")
});
using var image = SKBitmap.Decode("image.jpg");
var results = yolo.RunObjectDetection(image, confidence: 0.25, iou: 0.7);
image.Draw(results);
image.Save("result.jpg");You’re now running YOLO inference in pure C#.
YOLO inference accuracy is not automatic.
Preprocessing settings such as image resize mode, sampling method, and confidence/IoU thresholds must match how the model was trained. These settings directly control the accuracy–performance tradeoff and should be treated as part of the model itself.
📖 Before tuning models or comparing results, read:
👉 Accuracy & Configuration Guide
| Classification | Object Detection | OBB Detection | Segmentation | Pose Estimation |
|---|---|---|---|---|
![]() |
![]() |
![]() |
![]() |
![]() |
| image from pexels.com | image from pexels.com | image from pexels.com | image from pexels.com | image from pexels.com |
Hands-on examples are available in the demo folder, covering common real-world scenarios:
Including image inference, video streams, GPU acceleration, segmentation, and large-image workflows.
| Execution Provider | Windows | Linux | macOS | Documentation |
|---|---|---|---|---|
| CPU | ✅ | ✅ | ✅ | CPU README |
| CUDA / TensorRT | ✅ | ✅ | ❌ | CUDA README |
| OpenVINO | ✅ | ✅ | ❌ | OpenVINO README |
| CoreML | ❌ | ❌ | ✅ | CoreML README |
Each execution provider has its own README covering installation, runtime requirements, and provider-specific configuration.
Real-world usage examples and recommended settings can be found in the demo projects.
ℹ️ Only one execution provider package may be referenced.
Each provider ships its own native ONNX Runtime binaries; mixing providers will cause runtime conflicts.
YoloDotNet focuses on stable, low-overhead inference behavior, where runtime cost is dominated by the selected execution provider and model, not framework overhead.
📊 See: Benchmark methodology and results.
Internal benchmarks using BenchmarkDotNet across classification, object detection, OBB, pose estimation, and segmentation show that:
- Inference latency is stable after warm-up
- Performance scales cleanly with the selected execution provider (CPU → GPU → TensorRT)
- TensorRT precision modes (FP32, FP16, INT8) behave as expected
- Allocation behavior is predictable and bounded by output complexity
- Overall throughput is determined primarily by the execution provider and model configuration
For GPU-based providers, the first inference may be slower due to initialization or engine creation; subsequent runs operate at steady-state performance.
YoloDotNet is suitable for:
- Real-time pipelines
- Long-running services
- High-resolution image processing
- Deterministic production workloads
YoloDotNet uses a fully modular execution architecture that gives developers explicit control over native dependencies and runtime behavior.
- The core package is execution-provider agnostic
- Execution providers are delivered as separate NuGet packages
- Native ONNX Runtime dependencies are isolated per provider
- Fewer native dependency conflicts
- Cleaner and more predictable deployment
- Consistent behavior across platforms and runtimes
- Easier integration into production and long-running services
💡 Note for existing users
Projects upgrading from earlier versions must reference exactly one execution provider package and update provider setup accordingly. Existing models remain fully compatible.
YoloDotNet is built and maintained independently. If you’ve found my project helpful, consider supporting its development:
⭐ Star the repository
💬 Share feedback
🤝 Consider sponsoring development
Thank you. ❤️
https://github.com/ultralytics/ultralytics
https://github.com/sstainba/Yolov8.Net
https://github.com/mentalstack/yolov5-net
YoloDotNet is © 2023–2025 Niklas Swärd (GitHub)
Licensed under the GNU General Public License v3.0 or later.
Commercial use is permitted under the terms of the GPL v3; however, derivative works must comply with the same license.
See the LICENSE file for the full license text.
This software is provided “as is”, without warranty of any kind.
The author is not liable for any damages arising from its use.




