YoloSharp runs YOLO detection in .NET through ONNX Runtime

Detection without leaving the .NET process

YoloSharp is described as a high performance real-time object detection solution using YOLO11 and powered by ONNX-Runtime, and the primary language of the repository is C#. The pitch in one line is that you can run a YOLO model inside a .NET application, through ONNX Runtime, without hosting a Python process alongside it or shelling out to a separate inference server. The repository is under the dme-compunet organisation, the package is published on NuGet, and the licence is AGPL-3.0. The library covers the full set of YOLO vision tasks, and the README links the Ultralytics documentation for each one: Detect, OBB for oriented bounding boxes, Pose, Segment and Classify. That breadth is what separates it from a narrow wrapper. The same predictor type handles a detector, a pose estimator and a segmenter, which means an application that wants both detection and pose does not need two libraries or two model formats.

Three NuGet packages, and the choice between them

The installation story is a table of three packages rather than one, and the difference between them is the decision you have to make. YoloSharp is the CPU-based inference package and includes all runtime dependencies for all platforms. YoloSharp.Gpu is the GPU-based inference package, with the same dependency bundling. YoloSharp.Core is the core library without runtime dependencies, and the table says it has none, which makes it suitable for lightweight production or for using alternative runtimes. That last option is the interesting one for an engineer who wants control over the ONNX Runtime provider, because the core package leaves you to bring the execution provider and the native binaries yourself. The package is also what the C# code imports, through the Compunet.YoloSharp namespace, so the using directive tells you the original organisation name even though the distribution is on NuGet under the YoloSharp name.

The pipeline starts in Python: exporting the model to ONNX

YoloSharp does not ship models. The first step of using it is in Python, because the pre-trained weights are PyTorch models and the export path runs through the Ultralytics package. The code to do it is short.

from ultralytics import YOLO

# Load a model
model = YOLO('path/to/best.pt')

# Export the model to ONNX format
model.export(format='onnx')

That export step is the boundary of the whole design. Once you have an .onnx file, the Python toolchain is out of the picture, and the model becomes a file you version, ship and load from .NET. For a team that already trains models with Ultralytics, the pipeline is familiar. For a team that wants to run a published detector without touching Python at all, the export has to happen once, somewhere, by someone. The repository has an export/ directory at the top level, which suggests the conversion step is treated as part of the project rather than as something the user improvises.

Loading the model and running a prediction in C#

On the .NET side you add the package and create a predictor. The GPU and CPU variants are added the same way.

dotnet add package YoloSharp

The predictor is disposable, so it is held in a using declaration, and the detection call is either synchronous or asynchronous.

using Compunet.YoloSharp;

// Load the YOLO predictor
using var predictor = new YoloPredictor("path/to/model.onnx");

// Run model
var result = predictor.Detect("path/to/image.jpg");
// or
var result = await predictor.DetectAsync("path/to/image.jpg");

// Write result summary to terminal
Console.WriteLine(result);

Passing a file path and having the library load the image for you is the simplest entry point, and the DetectAsync variant is what you want in a service where you do not want to block a thread on inference. The result object prints a summary to the console directly, which is a small convenience that saves a separate formatting step when you are trying the model out.

Plotting results back onto the image

For previewing what a model actually did, the library offers a plotting layer, and it is built on ImageSharp. The example loads the image, runs a pose prediction against it, plots the results onto it and saves the result. The interesting detail is that the same Image object is used for both the input and the plotting, so you are not paying for a second decode.

using Compunet.YoloSharp;
using Compunet.YoloSharp.Plotting;
using SixLabors.ImageSharp;

// Load the YOLO predictor
using var predictor = new YoloPredictor("path/to/model.onnx");

// Load the target image
using var image = Image.Load("path/to/image");

// Run model
var result = await predictor.PoseAsync(image);

// Create plotted image from model results
using var plotted = await result.PlotImageAsync(image);

// Write the plotted image to file
plotted.Save("./pose_demo.jpg");

There is also a one-shot path for the common case.

using Compunet.YoloSharp;
using Compunet.YoloSharp.Plotting;
using SixLabors.ImageSharp;

// Load the YOLO predictor
using var predictor = new YoloPredictor("path/to/model.onnx");

// Run model, plot predictions and write to file
predictor.PredictAndSaveAsync("path/to/image");

The repository ships example images for each task, so you can see what Detect, Pose, Segment and OBB output looks like before you wire anything up.

Performance claims, and the two limits the project states

The README advertises high performance, and lists the techniques behind it: various techniques and use of .NET features to maximize performance, and reduced memory usage by reusing memory blocks and reducing the pressure on the GC. The memory point is the more concrete of the two, and it is the reason a native inference path is interesting in the first place, because ONNX Runtime's own buffer handling and the garbage collector are usually where the overhead shows up. What the README does not give is a benchmark, so the claims have to be read as design intentions rather than measurements. The two explicit limits are stated clearly, and they are the same two that appear in the not supported section. Batch processing is not supported, and you have to predict images one by one. Dynamic size is not supported, because the image is resized according to imgsz, which is the model's configured input size. For a video pipeline that is a significant constraint, since frame by frame inference through a per image call path is where the overhead accumulates.

Licensing: AGPL on the project, ImageSharp to check separately

The licence situation is the part to read twice. The project is under the AGPL-3.0 License, and the README adds an important note: the project depends on ImageSharp, and you should check the license details of that project separately. The reason that call-out matters is that ImageSharp has historically used a licence distinct from a permissive one, and a consumer of YoloSharp inherits that dependency by taking the package. The AGPL term on YoloSharp itself is the larger consideration for adoption. It is a network copyleft licence, so distributing a modified or unmodified binary linked against this library carries obligations that MIT or Apache would not, and running the library inside a service that users interact with over a network is exactly the scenario AGPL was written to reach. A team shipping a closed-source product built on YoloSharp needs to think about whether the obligation extends to that product, which is a question for a lawyer rather than for a README. The practical alternative is to keep the inference behind a thin internal service boundary you control, or to choose a differently licensed runtime.

Editorial conclusion

Adopt YoloSharp if your team works in .NET and needs object detection in the same process as the rest of your application, since a NuGet package and an ONNX model is all the integration it asks for. Do not adopt it if you need batch inference, because the documentation lists batch processing as not currently supported and requires you to predict one image at a time, and do not adopt it if you need dynamic input resolution, since the image is resized according to imgsz. Verify two things before you start: the licence of the ImageSharp package it depends on, which the project explicitly asks you to check separately, and that the AGPL-3.0 terms of YoloSharp itself fit your distribution model, since AGPL is a much heavier obligation than MIT or Apache when you ship a networked service. The practical first step is to export a model to ONNX with Ultralytics and load it with YoloPredictor on a single image.

Frequently asked questions

Official sources

1. dme-compunet/YoloSharp on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases