Why I Built an NHibernate XML to Fluent Converter

Here's how the meeting went:

"We should migrate to Fluent mappings."
"Agreed. The XML files are a maintenance nightmare."
"How many mapping files do we have?"
"About 80."
Silence.
"Let's revisit this next quarter."

That conversation — or some version of it — has happened on every NHibernate project I've worked on. Everyone agrees XML mappings are outdated. Nobody wants to spend weeks doing the conversion. So the XML files stay. For years.

What "80 files" actually means

Each XML mapping file needs to be manually translated to a ClassMapping<T> class. That means reading <id> elements and figuring out the correct Generators.* call. Reading every <property> and translating column names. Converting <bag> elements with cascade rules, inverse flags, lazy loading.

The cascade rules alone are a headache. all becomes Cascade.All. all-delete-orphan becomes Cascade.All | Cascade.DeleteOrphans. save-update becomes Cascade.Persist. You know this if you've done it. You still search Stack Overflow every time.

For 80 files, the estimate was two to three weeks of full-time work. Nobody has two to three weeks to spare on something that doesn't add a single feature.

The tool that makes "next quarter" into "this afternoon"

HbmToFluentConverter.exe Customer.hbm.xml

One command per file. The Fluent mapping class appears in the output folder. It handles ID generators, properties, many-to-one relationships, bag collections with one-to-many mappings, and cascade rules. For anything it can't handle — complex types, subclasses, unusual configurations — it adds a // TODO: comment.

That // TODO: approach was a deliberate design choice. In a real migration, you don't need 100% automation. You need 80% automation and clear markers for the 20% that needs human judgment. The tool gets you most of the way. You handle the edge cases, guided by the TODOs. An 80-file migration goes from weeks to a day or two.

A tool you use once

This might be the least "SaaS-brained" product I've built. You buy it. You run it once during a migration. You probably never open it again.

I'm fine with that.

Some tools earn their price through daily use. This one earns it by saving you weeks of miserable work on a single project. The value isn't in frequency — it's in magnitude. If it turns a three-week migration into a two-day migration, the EUR 10 price is a rounding error.

Also — if your company has 80 XML files today and is "revisiting next quarter," they had 80 XML files last quarter too. And they'll have 80 next quarter. Until something makes the migration painless enough to actually do.

Three products, one pattern

Product #1, #2, and #3 all follow the same principle: take something that already exists (JSON config, SQL file, XML mapping) and generate C# code you'd otherwise write by hand. They form the "Generate" layer of the toolkit.

After building three generators in two weeks, I was ready for something different. The next product wouldn't generate code — it would generate documentation. But that's another post.

Available on Gumroad for EUR 10.