AI and Machine Learning with .NET: Integration Guide for Developers

Search for AI in .NET and you'll find plenty of articles that list libraries. Seven of them, ten of them, each with a tidy bullet list of features. What they rarely tell you is which one to reach for first, and that's the question that decides whether your project stays clean or becomes a pile of overlapping SDKs.

The good news for 2026 is that Microsoft has settled much of this. This guide walks through the practical paths for AI integration in .NET applications, which libraries deserve your time, how to wire up OpenAI and RAG with real code, and where classic ML.NET still beats a language model. It all works on .NET 10, the current long-term support release.

Most AI features fall into one of four buckets. Choosing the bucket before the framework saves you from adopting tools you don't need.

Microsoft's own .NET AI ecosystem guide lands in the same place. Start with Microsoft.Extensions.AI, add the data libraries when you ground responses in your own content, and move to Agent Framework only when single prompts turn into multi-step workflows.

Here's where each library stands right now. A few have moved since the last round of comparison articles.

About Semantic Kernel: you'll still find it in plenty of codebases, and nothing stops it from running. But Microsoft's overview calls Agent Framework the direct successor, built by the same teams, and points to a migration guide. For a greenfield project, skip Semantic Kernel. For an existing one, plan the move for the next time you touch the orchestration code, not as a fire drill.

Here's the whole pattern for calling a model through Microsoft.Extensions.AI. Swap the client and the rest of your code stays put.

using Azure.AI.OpenAI;
using Azure.Identity;
using Microsoft.Extensions.AI;

IChatClient client =
    new AzureOpenAIClient(new Uri(endpoint), new DefaultAzureCredential())
        .GetChatClient("my-deployment")
        .AsIChatClient();

var reply = await client.GetResponseAsync(
    "Summarize this support ticket in two sentences: ...");

Console.WriteLine(reply.Text);

Two choices in that snippet matter. First, DefaultAzureCredential hands authentication to Microsoft Entra ID, so no API key sits in a config file, and the Azure SDK documentation marks Entra credentials as the recommended option. Second, the code only knows about IChatClient. Point it at OpenAI directly, or at a local model through OllamaSharp, and your calling code doesn't change.

In ASP.NET Core, register the client once and wrap it in middleware. Distributed caching, rate limiting, and OpenTelemetry tracing all plug in through the same builder, which is where this design pays off in production: cost control and observability, with no changes to the feature code.

One note if you're upgrading older code. The Azure.AI.OpenAI package is a companion to the official OpenAI library, and Azure's SDK team now suggests considering the OpenAI SDK on its own for broader model coverage and simpler authentication.

RAG sounds heavier than it is. You split your content into chunks, turn each chunk into an embedding, store the vectors somewhere searchable, and at question time retrieve the closest chunks and hand them to the model along with the question. In .NET, those jobs are split across small libraries: DataIngestion prepares content, VectorData stores and searches vectors, and Microsoft.Extensions.AI generates embeddings and calls the model.

Microsoft's vector search quickstart walks the full loop with an in-memory store, which is a good way to see the moving parts before you choose a database.

If your data already lives in SQL Server, you may not need a separate vector database. EF Core 10 added support for SQL Server's vector type, so you store embeddings in a column and search with LINQ:

public class Article
{
    [Column(TypeName = "vector(1536)")]
    public SqlVector<float> Embedding { get; set; }
}

var queryVector = new SqlVector<float>(
    await generator.GenerateVectorAsync(userQuestion));

var matches = await context.Articles
    .OrderBy(a => EF.Functions.VectorDistance("cosine", a.Embedding, queryVector))
    .Take(3)
    .ToListAsync();

That needs SQL Server 2025 or Azure SQL Database, and the indexed approximate-search features are still marked experimental in the docs. For other stores, such as Azure AI Search, the VectorData provider packages give you the same abstraction.

Whichever store you pick, ingestion quality decides answer quality. Microsoft's guidance says as much: plenty of AI apps fail before retrieval ever happens, because the source data is messy, oversized, or badly structured.

Not every prediction needs a language model. If you're scoring fraud risk, forecasting demand, or recommending products from your own tables, a trained ML.NET model runs in-process, has no per-call fee, and gives the same answer every time.

ML.NET 5.0 is the current stable release, and it trains and runs entirely in C#. The workflow is the same whether you're predicting churn or classifying tickets.

1. Define your data. A plain C# class with a label and the features you'll predict from.
2. Load and split it. Read a file or database query into an IDataView, then hold back a test set.
3. Build a pipeline. Chain data transforms and a trainer, or let AutoML try several options through Model Builder or the ML.NET CLI.
4. Train and evaluate. Fit the pipeline, check metrics on the held-out data, and save the model file.
5. Serve it. In ASP.NET Core, use PredictionEnginePool from Microsoft.Extensions.ML so concurrent requests don't collide.

ML.NET also has a side benefit for LLM work. Its Tokenizers library supports Tiktoken and Llama formats, so you can count tokens before you send a prompt and keep an eye on spend.

Plenty of teams train models in Python and still want to ship them inside a .NET app. ONNX is the bridge. Export the trained model to ONNX, load it in C# with an InferenceSession, and call Run. Separate packages cover CPU, CUDA GPUs, and DirectML, so the same model can use whatever hardware the app lands on.

That path suits low-latency scoring, offline apps, and data that can't leave the machine. For small language models on local hardware, ONNX Runtime GenAI adds the generation loop on top of the same runtime.

For new deep learning work, train in Python and export to ONNX instead of building around TensorFlow.NET. It still works, but ML.NET 5.0's own TensorFlow dependency points at TensorFlow 2.7, so it trails current Python releases.

Once the AI layer gets heavy, it often earns its own service: a worker that handles embedding jobs, or a Python model behind an API, scaled separately from the main app. That's an ordinary microservices decision, and our .NET microservices architecture guide covers how to draw those boundaries. If several assistants or apps need the same tools, expose them once over Model Context Protocol instead of rebuilding each integration.

Agents are a different step up. When a single prompt becomes a multi-step workflow with tools, routing, and handoffs, Microsoft Agent Framework is the tool. Version 1.0 shipped in April 2026 for both .NET and Python, with stable APIs and long-term support. If that's where you're headed, start with our guide to building AI agents on Azure, then work through a real-world AI agent built with Agent Framework, Foundry, MCP, and Aspire for the code-level detail.

Plenty of these don't need a language model at all. Matching the tool to the problem is most of the skill here, and it's usually what keeps both costs and surprises down.

Keyless authentication through Microsoft Entra ID is the default to aim for. Beyond that, decide up front what data is allowed to reach a hosted model at all, and log prompts and responses the way you'd log any other external call. If compliance requires your data to stay under your own Azure governance, Azure OpenAI is the usual route.

Hosted models bill by tokens, so cost follows how much text you send. Budget with the caching and token counting covered above, then review real usage monthly instead of trusting the estimate.

Then measure quality. AI behavior shifts whenever prompts, models, or tools change, which is why Microsoft ships a Microsoft.Extensions.AI.Evaluation library as a regression layer. Add it as soon as the feature is useful enough to protect.

A chat feature on top of a hosted model is a reasonable first project for a strong .NET team. Document search over regulated data, models that touch money or health decisions, or an architecture spanning several services is a different job. That's the point to hire .NET developers who've shipped AI features before, and an AI consulting team can help you choose the right path before anyone writes code.

The expensive mistake is picking the wrong path: a language model where ML.NET would do, or a vector database nobody needed. Buoyancy Software's custom application development team designs and builds AI-powered .NET applications with the right approach settled up front.

Book a free consultation and get a straight recommendation on where AI fits in your application.

Prev Blog

Azure Microservices Architecture: Deployment, Best Practices and Examples

Next Blog

Accelerating BOMS: From Concept to Global Launch in Just 90 Days