YAF.NET: a long-running ASP.NET forum with a .NET Core rewrite in progress

Two products in one repository, and which one you actually get

The most important thing to understand about YAF.NET is that the repository contains two different generations of the software, and the branch you clone decides which one you get.

The netfx branch contains the current stable YAF 3.2.x release, and the master branch contains the current beta of YAF 4.x.x. The prerequisites line up with that split exactly. YAF 3.2.x needs ASP.NET on .NET Framework 4.8.1, and YAF 4.x needs ASP.NET Core 10.0. The default branch of the repository is master, so a clone with no arguments gives you the beta.

That is a genuine trap for anyone evaluating the project, and it is a reasonable question to ask which branch you should be on. If you are running a production forum today, the answer is the netfx branch, at the cost of being on .NET Framework, which on a current Windows Server means .NET Framework 4.8.1 rather than anything newer. If you are starting a new deployment and your hosting runs modern .NET, the answer is the 4.x beta on master, with the understanding that a beta is a beta.

The project is at yetanotherforum.net, and the release history shows both lines moving in parallel. The tags are v4.0.8 on 2026-08-10, v3.2.16 on 2026-08-29 and v4.0.9 on 2026-08-30, so the 3.2.x line is still receiving releases rather than being frozen, which tells you the .NET Framework branch is a maintained product and not an abandoned one.

The repository layout is simple at the top level, with a `yafsrc/` directory holding the application and everything else being project files. There is a BUILDING.md for compiling from source, a CHANGES.md for the change history, a SECURITY.md, and a LICENSE.md.

The project is licensed under the Apache 2.0 licence, the repository is not archived, and the last push was on 2026-10-20.

What the project says about itself and how the quality gate works

The project describes itself as an international collaboration of like-minded, skilled and creative individuals who are striving to make YAF.NET among the most capable and malleable forum solutions available. It is a volunteer project, and the description does not hide that.

The infrastructure badges are more informative than the prose. There is a SonarCloud quality gate badge pointing at the SonarCloud dashboard, which is a static analysis service that computes a set of code quality measures and, in the gate configuration, fails the build when they regress. A forum project that wires a quality gate into its pipeline is making a statement about how it handles change.

There are two separate build badges, one for the main build workflow and one for the netfx build, which matches the two-branch model described earlier. A build workflow that is aware of the .NET Framework line has to run on a different runner configuration than the .NET Core one, since the Core SDK does not build .NET Framework projects, and the two badges in the project description reflect that split.

There is also a Docker pulls badge for the yafnet/yafnet image on Docker Hub, so a container image is published and pulled by other people, and the pulls count is a rough indicator of how many deployments exist in the container form. The project publishes a Docker image at hub.docker.com/r/yafnet/yafnet, and the screenshot assets in the project description are served from the wwwroot assets directory inside the source tree, which tells you the frontend build output lives with the application rather than in a separate repository.

The frontend is worth noting as a limitation rather than a feature. The screenshots of the main screen, the forums list, the topics screen and the admin control panel are static images in the project description, and the paths point at .webp files under `yafsrc/YetAnotherForum.NET/wwwroot/assets/`. The templates and styles are part of the same tree, which for a project started well before the current generation of ASP.NET front ends means the look is what it is unless you rewrite the theme yourself.

Installing, upgrading, and the DNN module

The project documentation is on the GitHub Wiki, and the project description is upfront that it is preliminary. The wiki covers building the source, new installation, and upgrading an existing YAF.NET installation, and all three are wiki pages rather than documents in the repository, which means the install instructions live outside the versioned tree.

That has a practical consequence. A wiki page can change without a release, so the instructions you follow may not correspond to the commit you are running, and there is no versioned copy of them to diff against. For a database-backed application with a schema that changes between versions, that matters, and it is the reason to read the upgrade page carefully rather than treating it as a formality.

The upgrade path is called out separately from a new installation, with its own wiki page, which tells you the project treats an upgrade as a real operation with its own steps rather than as replacing binaries. That is the correct expectation for any forum software, because the database schema, the file store for attachments and the configuration all have to move together.

There is a third distribution route for the 3.x line. YAF v3.x.x is also available as a DNN Module, downloadable from the separate YAFNET-DNN project on GitHub. DNN is a .NET content management system, and shipping as a module means the forum can be installed into an existing DNN site as one of its extensions rather than as a standalone application. That is a real deployment option for organisations that already run DNN, and it is only offered for the 3.x line, not for 4.x.

So the three routes are: the standalone application from either branch, the DNN module for 3.x, and the Docker image. The wiki also has a page for building the source, which is what you need if you intend to customise the templates or the code rather than only configure the forum.

The community support forum, and what it tells you about the project

YAF.NET is unusual among open source forum software in documenting a live community support forum as the primary support channel, and the project description points at yetanotherforum.net/Forums for questions.

The interesting part is that this is a genuine dogfooding arrangement. The support forum is a YAF installation, running the software it documents, which means the maintainers and the community run the same code path as their users. When a question comes in, the person answering is looking at the same interface and the same configuration screens.

It also tells you something about the project's shape. A software project with a busy support forum is one that has a user base rather than a hobby following, and the volume of questions is a rough proxy for the size of the installed base. A forum software with no user community would not be able to afford that.

For an evaluator, this cuts both ways. It is a signal of adoption and of a maintainer presence, and the maintainers are reachable. It is also a signal that support is peer to peer rather than contractual, so a commercial deployment inherits a support model where the answer to a hard question comes from another user, possibly days later.

The presence of a SECURITY.md at the repository root is a related signal, and a welcome one for a project with a public attack surface. A forum holds user accounts, email addresses and private message content, so its vulnerability history is a genuine risk factor, and a published security policy is how you find out whether someone is maintaining that surface.

The project description also makes a distinction between documentation and support. Questions go to the community forum, and the wiki is where the more permanent information lives, and the description points at both depending on whether you need an answer or a procedure.

Where YAF.NET is the wrong choice

The first limit is the .NET Framework dependency on the stable branch. YAF 3.2.x requires ASP.NET on .NET Framework 4.8.1, which is fine on Windows Server but means the 3.x line is not a candidate for a Linux deployment, and for a Windows deployment it means your application runtime is the one Microsoft is no longer extending. If your organisation has a policy against .NET Framework, the stable branch is out and you are choosing the beta.

The second limit is the beta. The 4.x line is described as beta, and a beta forum software is a real risk for a site with real users and real content, particularly one that has to be backed up and restored.

The third is the front end. The templates and assets are part of the application tree and reflect an older generation of ASP.NET UI. A forum with a distinctive design, a modern look or a mobile-first layout is a theme rewrite for you, not a configuration change.

The fourth is what a forum software is not. There is no built-in search engine of the kind a large community needs, no structured plugin marketplace comparable to what WordPress or Discourse have, and no documented API for building a separate client against. For a community that will grow, the ecosystem around the software matters as much as the software, and a mature .NET application that has been developed for a long time is not the same as a modern forum with a plugin architecture and a headless API.

Compare that with Discourse, which is a Rails application with a plugin system, a REST API and a modern front end, and with MediaWiki or phpBB, which have large plugin ecosystems. The difference in approach is that YAF.NET is a self-contained ASP.NET application you configure and extend by forking, while those platforms are designed around third-party extension. For a corporate intranet forum with a stable membership and a volunteer admin, a self-contained application is easier to run. For a public community that expects to grow, the ecosystem gap is the deciding factor.

Licence, release state and what to check before you install it

Yet Another Forum.NET is licensed under the Apache 2.0 licence, with the licence text in the LICENSE.md file at the repository root. Apache 2.0 is permissive and includes an express patent grant, which is a reasonable fit for web software you host yourself and may modify. Read the LICENSE.md file yourself for the exact terms, and note that this is a licence position for the source, not advice on how to comply with it.

The release state is good, and it is a point in the project's favour. The recent tags are v4.0.8 on 2026-08-10, v3.2.16 on 2026-08-29 and v4.0.9 on 2026-08-30, with the last push on 2026-10-20, so both lines are moving and the tree is a couple of months ahead of the last release. The repository is not archived, the default branch is master, and the CHANGES.md file at the top level is where the change notes live rather than the wiki.

The build badges and the SonarCloud quality gate are worth reading as maintenance signals rather than as decoration. A project with a working CI on both branches and a quality gate that can fail is one where a broken commit is caught before it reaches a release, which is more than a good number of volunteer projects manage.

What to check before you install it is a short list, and the first item is the branch. Decide explicitly between netfx for the stable 3.2.x line on .NET Framework 4.8.1 and master for the 4.x beta on ASP.NET Core 10.0, because cloning the default gives you the second one and the prerequisites differ entirely.

Then read the wiki pages for new installation and for upgrading an existing installation, and note that the documentation is described as preliminary and lives in the wiki rather than in the repository, so save a copy of the pages you follow alongside your configuration. If you are deploying the 3.x line into an existing DNN site, use the DNN module project instead of the standalone application, and remember that path is only offered for 3.x.

Finally, if you are upgrading an existing installation, take a database and attachment backup before you start and follow the upgrade page rather than replacing files, because the schema and the file store both have to move together.

Editorial conclusion

YAF.NET fits an organisation that wants to run its own forum on ASP.NET, that needs a working stable line today, and that is willing to accept a .NET Framework 4.8.1 dependency on the stable branch or a beta on the Core branch. It does not fit a team standardising on modern .NET with no appetite for a beta, and it does not fit a project that needs a modern front end, since the templates and JavaScript are long-standing. Before you adopt it, decide which branch you are running, because the netfx branch and the master branch are different products with different prerequisites, and read the wiki pages for new installation and for upgrading an existing installation rather than assuming an upgrade is a file copy.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. YAFNET/YAFNET on GitHub