msgraph-sdk-dotnet: the .NET client for Microsoft Graph, generated by Kiota

The client is a generated surface over a REST API

The Microsoft Graph .NET Client Library exists to integrate the Microsoft Graph API into a .NET project, and it targets .NetStandard 2.0, which is the reason it works across .NET Framework, .NET Core and .NET 5 and later without a separate package per target. The shape of the library is that the requests follow the format of the Microsoft Graph API's RESTful syntax, so a Graph endpoint such as /me/drive maps onto a property path in C# rather than a hand-built URL. The core object is GraphServiceClient, and an instance of it handles building requests, sending them to Microsoft Graph API, and processing the responses. You supply an IAuthenticationProvider when you construct it, and that provider is what authenticates the requests. Since v5 the SDK uses Kiota for code generation, which is the detail that most affects an existing codebase.

Requests read like paths and return typed objects or throw

The request style is worth looking at concretely, because it is where the ergonomics live. To retrieve a user's default drive:

var drive = await graphClient.Me.Drive.GetAsync();

GetAsync returns a Drive object on success and throws an ApiException on error, so error handling is exception-based rather than a result type. To get the current user's root folder of their default drive, you take the id from the drive and index into it:

// Get the user's driveId
var drive = await graphClient.Me.Drive.GetAsync();
var userDriveId = drive.Id;
// use the driveId to get the root drive
var rootItem = await graphClient.Drives[userDriveId].Root.GetAsync();

which returns a DriveItem on success and throws an ApiException on error. The indexer syntax for a collection by id is the pattern to get used to, and it is also where a generated SDK's behaviour is least obvious, which is why the project ships a Collections document alongside the overview and errors documents.

Authentication goes through Azure.Identity credential classes

The getting started sequence is four steps, and the second is the one that takes the most planning. Step one is to register your application to use the Graph API through the Microsoft Application Registration Portal. Step two is to authenticate for the Microsoft Graph service, and the library supports the use of TokenCredential classes in the Azure.Identity library, with examples on setting up TokenCredential instances in docs/tokencredentials.md. The recommended library for authenticating against Microsoft Identity, Azure AD, is MSAL. Step three is to create the GraphServiceClient with an authentication provider, and step four is to make requests. The design point is that the SDK does not own your credential: it takes an IAuthenticationProvider and delegates, which means you can use whatever token source your application already has, and it also means the SDK is not the thing you debug when a token fails.

Installing is one NuGet package

The installation is either a search for Microsoft.Graph in the NuGet library, or the command below in the Package Manager Console:

Install-Package Microsoft.Graph

The package is published as Microsoft.Graph, with the NuGet listing linked from the README, and the SDK documentation is hosted at graph.microsoft.com. The repository is a full solution, Microsoft.Graph.sln, with src/, tests/, build/, docs/, scripts/ and a guard/ directory, and it carries the tooling for a Microsoft release process including a .release-please-manifest.json, a release-please-config.json, Azure Pipelines definitions in .azure-pipelines/ and a THIRD PARTY NOTICES file. GitHub lists its licence as a custom one it cannot classify, with LICENSE.txt at the root, so for a component you will ship inside a product the file itself is what needs reading.

The v1 to v5 upgrade path is where the work is

The Notes section is a summary of three major upgrades, and it is the most practically useful part of the README. Between 1.x and 3.x there were minor possibly breaking changes: the .NET Standard minimum version bumped from netStandard1.3 to netstandard2.0, the .NET Framework minimum bumped from net45 to net461, the enum order for GiphyRatingType changed, ParticipantInfo became InvitationParticipantInfo and CallRecordRequestBody became CallRecordResponseRequestBody. Between 3.x and 4.x there were major breaking changes: the .NET Standard minimum moved to netstandard2.0, .NET Framework to net462, Newtosoft.Json was replaced with System.Text.Json and the Microsoft.Graph.Core dependency went to 2.0.0. Between 4.x and 5.x there were several major breaking changes, as the SDK now uses Kiota for code generation. Each step has its own upgrade guide in the docs/ directory, upgrade-to-v4.md and upgrade-to-v5.md.

A bimonthly schedule, and a large sample library

The update schedule is stated plainly: the Microsoft Graph .NET Client Library is scheduled to be updated during the second and fourth week of each month, which is a useful commitment when you are planning an upgrade window. The releases move quickly to match, with 6.6.0 on 2026-09-02, 6.7.0 on 2026-09-16 and 6.8.0 on 2026-10-06, and the repository is not archived with the last push on 2026-10-06. The README also lists a wide set of sample applications that ship as separate repositories, including UWP connect, snippets and MeetingBot samples, ASP.NET 4.6 connect and snippets samples, and Xamarin.Forms snippets, connect, meeting manager and property manager samples. Those are worth having on hand because they show the same SDK used from four different host stacks, which is usually the fastest way to find out how the request builder behaves in your own application type.

What this SDK is not for

The limits are structural and worth stating before you adopt it. The first is that the surface is generated, which means you are constrained by what the generator emits. You cannot add a convenience method to the generated request builders, and when Kiota changes how it names or shapes things, the diff touches your whole codebase rather than one method. The second is that the library is scoped to Microsoft Graph, so it is not a general HTTP client for Microsoft services, and its version numbering, with three documented major breaking changes in the first five versions, signals a surface that is still moving. The third is the exception model. GetAsync throwing an ApiException is fine in a service, but in an application with a UI it means every call needs a try, and the error shape is defined by the service rather than by a discriminated union you can pattern match. None of that is a reason to avoid the SDK, since the alternative is hand-writing the same requests, but it is a reason to plan the upgrade from v4 early rather than late.

Editorial conclusion

Adopt msgraph-sdk-dotnet if you are building on Microsoft Graph from .NET and you want generated request builders with typed paths instead of hand-written HTTP calls. Do not adopt it expecting the v4 API shape, because v5 replaced the hand-written builders with Kiota generation and the upgrade guide exists precisely because the surface changed. Before you commit, read docs/upgrade-to-v5.md, confirm the TokenCredential flow in docs/tokencredentials.md, and check the collection paging behaviour in docs/collections.md, since that is where a generated SDK most often surprises you.

Frequently asked questions

Official sources

1. Issues
2. microsoftgraph/msgraph-sdk-dotnet on GitHub
3. Project website
4. README
5. Releases