DSharpPlus: a .NET wrapper for the Discord API, best used on nightly

Unofficial means the API can move under you

DSharpPlus is an unofficial .NET wrapper for the Discord API, and it is the continuation of DiscordSharp. The licence is MIT, and the code of conduct and contributing guidelines are in the repository, along with a Discord server that the project uses for development discussion.

Unofficial is a factual description of the risk, not a marketing choice. Discord publishes an API and the community maintains a wrapper for it, so the wrapper has to absorb every change Discord makes. The repository layout shows how much of the surface there is to maintain. The core library is in DSharpPlus/, and there are separate directories for the extensions, DSharpPlus.Commands/, DSharpPlus.CommandsNext/, DSharpPlus.Interactivity/, DSharpPlus.Voice/ and DSharpPlus.Http.AspNetCore/, plus DSharpPlus.Analyzers/ for the Roslyn analysers and DSharpPlus.Tests/ for the test project.

The solution file is DSharpPlus.slnx, the newer XML solution format, and the build is centralised through Directory.Build.props and Directory.Packages.props, which is how a repository this size keeps package versions in one place.

There is also an obsolete/ directory in the tree, which is a small thing worth noticing. A wrapper that has lived through several generations of the Discord API has a history of renamed and removed members, and having the old ones kept in a separate project makes the deprecation trail visible in the source rather than only in release notes.

Nightly is the recommended channel, and the docs only cover it

The versions section of the README is unusually direct about what to install.

Nightly versions are published to NuGet as a prerelease, and the README says you should, as a rule, use these versions. The reasoning is given: despite not being marked as stable, they are held to high standards of quality and merely represent the latest, most up-to-date state of the library. The documentation section says the same thing from the other side, with documentation for the latest nightly at dsharpplus.github.io, a note that stable version documentation is not currently hosted, and an instruction to use nightly versions whenever possible.

That is an unusual position for a library, and it follows from the nature of the API. A bot library that lags behind the platform breaks, and the fix for a broken bot is usually to move to the build that already handles the new API shape.

Stable releases exist as well, and important bugfixes are backported to the latest stable release. The stable line follows romantic versioning rather than semantic versioning, and the README explains the three numbers. A major version indicates very major changes to both the library surface and internals, a minor version indicates major additions or breaking changes as necessary and in limited scope, and the third number indicates hotfixes or small features as necessary.

The recent history shows how the two channels relate. v4.5.3 came out on 2026-08-24, v4.5.2 on 2026-04-14, and v4.5.1 on 2025-04-16, so the stable line moves a few times a year while the nightly line moves continuously.

The core package leaves out Voice and HTTP on purpose

The extension table is the clearest statement of the library's scope. The main DSharpPlus library provides all features of the API except Voice and HTTP interactions, and those arrive through additional packages.

DSharpPlus.Commands is an extension that provides a command framework for both messages and application commands, which is the piece that turns a bot from a script that reacts into something with a command surface. DSharpPlus.Interactivity provides utilities for interactive flows with your users, which covers the questions, prompts and reactions that make a bot usable. DSharpPlus.Voice enables connecting to Discord voice channels, and DSharpPlus.Http.AspNetCore provides support for HTTP interactions and webhook events, which is how Discord reaches a bot that is not holding a gateway connection open.

The split is a dependency decision rather than a design preference. Voice needs native audio and encryption libraries, and HTTP interactions pull in ASP.NET Core, and a bot that does neither should not carry them.

The project also lists third party extensions it is willing to recommend in good faith, and they are the Lavalink integrations, Lavalink4NET.DSharpPlus for stable versions and Lavalink4NET.DSharpPlus.Nightly for nightly ones. The existence of a nightly twin of the same extension is a good illustration of how the two channels propagate, and if you write an extension yourself, the project asks you to send a pull request or talk to them on Discord to get it listed.

The native packages carry the compression and the encryption

DSharpPlus also publishes a set of native libraries packaged as NuGet packages, and they exist because the features that need them cannot be done in pure managed code.

DSharpPlus.Natives.Zstd enables zstd compression for the gateway, and the README notes that DSharpPlus picks this up by default and uses it. DSharpPlus.Natives.Sodium provides the encryption support required for Voice and for DSharpPlus.Http.AspNetCore. DSharpPlus.Natives.Opus provides the native audio encoder for Voice, DSharpPlus.Natives.Speex provides resampling support for Voice, and DSharpPlus.Natives.Koana provides the required end to end encryption support for Voice.

The README also makes the point that these are simply native libraries packaged as NuGet packages, so they can be used from anywhere and not only from DSharpPlus bots. That is a helpful detail, because it means the dependency is not a hidden part of the library but a package you can reference directly.

For a bot that only sends messages, none of this matters, and the zstd package being picked up automatically is the only one that touches an ordinary bot. For a voice bot, all five are involved, and the encryption ones are not optional extras but a requirement of the protocol.

Testing a pull request build before it becomes a release

The README explains how to install the library locally, and the interesting case is the one where you want to test someone else's in-flight change.

For your own local changes, you clone the repository and reference the project directly from your csproj file.

<ProjectReference Include="../DSharpPlus-Repo/DSharpPlus/DSharpPlus.csproj" />

The README notes that the library should not be in the same directory or a subdirectory of your project, and that this method should only be used if you are making local changes to the library.

For a pull request, every commit is built into packages that can be downloaded from GitHub. You navigate to the pull request, click the checkmark next to the latest commit hash, then Details, then Summary, and scroll to the bottom, where there is an artifact named DSharpPlus-PR-<PR number>-<Incrementing build number>. You unzip it and add the folder as a package source, either from the command line.

dotnet add package <package-name> --source "path/to/your/package/folder"

Or by adding the folder to your csproj, in the PropertyGroup.

<RestoreAdditionalPackageSources>path/to/your/package/folder</RestoreAdditionalPackageSources>

This is a detail that matters for anyone who reports a bug in a bot. The fix often exists in a pull request before it exists in a release, and this is the documented way to try it.

Contributions are welcome, generated code is not

The contributing section is short and has one rule that is stated more firmly than the rest.

Pull requests should generally target the master branch, which tracks the latest development state, or a specific feature branch if you want to collaborate on that feature. There are contributing guidelines and a code of conduct in the repository, and the project recommends talking to them first in the Discord server, in the #lib-development channel, to see whether a change would be taken as proposed before doing the work. The necessary role is available during onboarding or in the channels and roles settings, and the Discord server is also where questions about the library's development are answered.

The rule: by contributing you agree to make your code available under the MIT licence and to confer that licence upon it, code from other people must be used in compliance with their licence and clearly marked as such, and AI-generated code cannot be submitted.

That last clause is unusual enough to be worth naming plainly, because most projects say nothing about it and a few say the opposite. Here the project has closed that door, and the practical effect for a contributor is that a patch has to be your own work or clearly attributed third party code under a compatible licence.

The tutorials and example bots are listed under resources, and the README says those resources apply only to the latest stable version, which is worth noting next to the instruction to use nightly.

A mature library with a small, honest support surface

The repository is not archived and the last push was on 2026-09-23, so the library is being worked on. The release history is a steady line of 4.5.x versions, with 4.5.1 in April 2025, 4.5.2 in April 2026 and 4.5.3 in August 2026.

What the project offers as support is a Discord server, a GitHub issue tracker and documentation hosted for the nightly build. There is no separate support package, no commercial tier and no long term support branch for the stable line, and the README says nothing that suggests one is planned. The maintenance services that a bot operator might want, the kind of thing that keeps a gateway client working as Discord changes, are the responsibility of whoever runs the bot.

That is a reasonable arrangement for a library with a permissive licence and an active community, and it is also a shape to plan around. A bot that matters to a business should be pinned to a version, monitored for gateway errors, and upgraded on a schedule rather than left to float on nightly, even though the project recommends nightly.

For a first bot, the tutorial for making your first bot in C# and the Example-Bots repository are the two starting points, and the fact that the tutorial is explicitly for the latest stable version tells you which one will still match the code you are reading.

Editorial conclusion

DSharpPlus fits a C# team writing a Discord bot that needs the command framework, interactive flows, voice or HTTP interactions, and that accepts a prerelease dependency in exchange for the library moving with the Discord API. It does not fit a production service that has a policy against prerelease packages, since the project tells you to use nightly, and it does not fit a team that needs the API surface documented for a specific pinned stable version, because stable documentation is not hosted. Verify three things before you commit: which channel you are pinning, nightly or the last stable, that the package you need exists in the channel you chose, since the extension packages and the native packages version separately, and that the native packages are present if you use voice, HTTP interactions or the compressed gateway, because the encryption and encoding support lives in them rather than in the core library.

Frequently asked questions

Official sources

1. DSharpPlus/DSharpPlus on GitHub
2. License: MIT
3. Project website
4. README
5. Releases