NHibernate: a .NET ORM whose README describes a .NET Framework project shipping on .NET
NHibernate Object Relational Mapper
At a glance
- What is it?
- 2,173 stars, 931 forks and 667 open issues. The distribution guidance is a heading with no version in it, and the nightly feed URL points at a v3 path for a project on its fifth major line.
- Who is it for?
- NHibernate's documentation makes the most sense read as a document about the project's history, because almost every section names a piece of infrastructure that has since been superseded. Google Groups forums, TeamCity, a JIRA tracker, SourceForge binaries and a Nant build are all listed as current facts in a repository whose most recent releases came out in 2026.
- Can I use it commercially?
- Yes, with conditions. LGPL-2.1 is a weak copyleft licence: you can use it inside commercial and closed-source software, but if you distribute changes to its own files, you must publish those changes under the same licence.
- Is it still maintained?
- Yes. The repository last received commits 3 days ago.
- What is it written in?
- Mainly C#, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 11, 2026, and from our analysis. They are not legal advice.
Editorial analysis
A README that opens by naming an older .NET
The opening sentence calls NHibernate a mature, open source object relational mapper for the .NET framework, and follows it with the claim that it is actively developed, fully featured and used in thousands of successful projects. Then it points at the community site for how-tos, blogs and reference documentation, and that is where the README's technical content stops.
The phrase .NET framework is the first thing a new reader will notice, because the repository topics list `dotnet-core` and `dotnet-core2` alongside `c-sharp`, `dotnet`, `linq`, `linq-provider`, `criteria-api` and `orm`. So the same repository describes itself in framework terms in its prose and in runtime terms in its tags. Both statements have been true at different points in the project's life, and the README simply never got updated to say which one is current.
The scale is worth registering. The project reports 2,173 stars and 931 forks, a fork ratio close to 43 percent that fits a library embedded in application codebases, and 667 open issues, which is a large open backlog for a project at this level of adoption. The last push on record is 2026-09-22.
A heading called Latest Release Version with no version under it
The distribution section is where the README's gaps become concrete. It has a heading for the latest release version, and immediately under that heading it explains that the quickest way to get the latest release is to add it to a project using NuGet, with a link to the package page. It then says binaries are also available from SourceForge.
So the section named for a version never states which version that is. The actual numbers are only in the release history, and they are not a simple sequence. Version 5.7.0 was published on 2026-06-30. Version 5.6.1 came after it, on 2026-05-22, and version 5.6.2 came later still, on 2026-09-22, the same day as the last recorded push.
The ordering tells the story. Two maintenance lines are running in parallel, the 5.6 series receiving patches after 5.7.0 shipped, and each release points at a different milestone on the issue tracker, 77 for 5.6.2 and 73 for 5.7.0, with 74 for 5.6.1. Each release note also tells you to read the release notes, which is the project's own advice about breaking changes.
For an adopter, the practical consequence is that the highest number is not automatically the safest choice, and the README gives you no basis for choosing between the lines. Deciding means reading the release notes for both.
The nightly feed path says v3 in a repository on version 5
Development builds are distributed through a Cloudsmith feed, and the README explains how to register the package source in a `NuGet.Config` at the top of a project.
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<packageSources>
<add key="NHibernateDevBuilds" value="https://nuget.cloudsmith.io/nhibernate/nhibernate-core/v3/index.json" />
</packageSources>
</configuration>The feed path ends in a v3 segment. The repository is named `nhibernate-core` because that is where the mapping code lives, but the versions it publishes are 5.x, and the package name on NuGet is `NHibernate` rather than `nhibernate-core`. So a reader looking for the current build finds a v3 path in the official documentation.
There is a defensible reading, which is that the v3 refers to the Cloudsmith repository layout rather than to the package version, and Cloudsmith does version its index endpoints. But nothing in the README says so, and the sentence immediately around it is about getting the latest development build. The cheap check is to open the feed URL from the README and look at what versions it lists; the expensive mistake is assuming a v3 path means a v3 package.
The surrounding text is warm in a way few technical READMEs are, spending a paragraph on how good a thing Cloudsmith is and including a hosted-by badge. That paragraph is the only Cloudsmith content that matters to a consumer, and it is the reason the feed exists at all, since the package hosting is donated.
Google Groups forums presented as the official support channel
The README names two official community forums, a users forum and a development forum, and links both as Google Groups. Google Groups has been in a long wind-down, and a project that points its official support channels at it in 2026 is pointing at infrastructure that most users will find difficult or impossible to use.
The bug reporting guidance is more durable and, notably, more demanding than the support guidance. It directs reports to the GitHub issue tracker, states that a test case demonstrating the issue is usually required, and links both a contributing guide and a blog post from 2008 on the best way to submit a bug, namely a good unit test. The date on that post is a fair signal of how long this project has been asking for the same thing.
Both pieces of guidance point at different expectations: the forums for questions and the tracker for defects, with the tracker demanding reproducible evidence. That division is sensible, but the forum half is aimed at a service that is no longer a reliable destination.
Credits that read as an inventory of retired build tooling
The credits section thanks, in no particular order, a list of projects and services that maps the project's history better than any changelog could. Unit testing comes from NUnit. Build automation comes from Nant, which is a build system that predates the current .NET tooling. Continuous integration is credited to TeamCity, hosted for the project, alongside CodeBetter. Source control is credited to GitHub and SourceForge, and the bug tracker is credited to JIRA and Atlassian.
None of those are the tools a contributor today would reach for. The tree tells a different story: `build.ps1`, `psake.ps1`, `global.json`, `build-common/`, a `teamcity.build` file, `GaRelease.bat` and `ShowBuildMenu.sh`, plus a `Tools/` directory. There is still a TeamCity build definition checked in, and there are shell and batch release helpers sitting beside a PowerShell script, which suggests build and release work happens on several systems rather than one.
Two credits do point at the present. Relinq is named as a LINQ provider for NHibernate, which lines up with the `linq` and `linq-provider` topics, and AsyncGenerator is credited as a Roslyn based async code generator. The proxy implementation credit names LinFu and the person behind it, and one entry credits code taken from a CodeProject article, which is the kind of provenance note that makes a licensing review slower but easier.
There is also a `SECURITY.md` at the repository root, which the README never mentions.
Licensing is dual, and the documentation terms are separate
The license section is precise, which is more than can be said for most of the rest of the README. The software is distributed under the Lesser GNU Public License version 2.1, with the license file at the repository root. The documentation is distributed separately under the GNU Free Documentation License version 1.1, with its own license file under the documentation directory.
That split matters for anyone copying material out of the project. The reference manual carries different terms from the code, and the README is explicit that the documentation license is version 1.1 of the FDL, which is an old version of that license. The dual arrangement is inherited from the project's Java origin, where a similar pairing was conventional, and it has been carried forward without simplification.
The repository metadata reports the license as LGPL-2.1, which matches the README's first statement and omits the second. So the metadata is not wrong, it is just incomplete in the same way the language field is incomplete.
Editorial conclusion
NHibernate's documentation makes the most sense read as a document about the project's history, because almost every section names a piece of infrastructure that has since been superseded. Google Groups forums, TeamCity, a JIRA tracker, SourceForge binaries and a Nant build are all listed as current facts in a repository whose most recent releases came out in 2026. None of that makes the mapper obsolete, and the version numbering shows a project still maintaining parallel lines rather than winding one down. What a new adopter should do is ignore the credits section, install the package named NHibernate from NuGet, and read releasenotes.txt for the specific version, since the README's own Latest Release Version heading never states a version at all.
Frequently asked questions
How do I install the latest NHibernate release?
Add the package named NHibernate from NuGet to your project, which the README calls the quickest route. Binaries are also published on SourceForge. Note that the section headed Latest Release Version never states a version, so check the release list, since the 5.6 and 5.7 lines were being maintained in parallel.
How do I get nightly development builds of NHibernate?
Register the Cloudsmith feed as a package source in a `NuGet.Config` at the top of your project, using the URL given in the README. Be aware that the feed path in that URL ends in a v3 segment even though published versions are 5.x, so open the index and confirm which versions it lists.
Is NHibernate the same as Java's Hibernate?
NHibernate is a port of the Hibernate object relational mapper to the .NET platform, and its documentation site, package naming and naming conventions reflect that lineage. It is a separate implementation with its own release line, its own LINQ provider and its own bug tracker, not a wrapper around the Java library.
What license does NHibernate use?
The code is under the Lesser GNU Public License version 2.1, and the documentation is under the GNU Free Documentation License version 1.1 with a separate license file. Repository metadata reports only the LGPL, so read the license section rather than the metadata field if documentation terms matter to you.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/nhibernate-nhibernate-core)