LLBLGen Pro Support System Feature requests feed

Future of LLBLGen by Otis

Otis — Sun, 19 Jul 2026 07:24:33 GMT

DvK wrote:

Hi,

Just curious about what new things or implementation of new database-engine features are up for LLBLGen? It's still a very solid ORM which has a place in the current landscape of modern application development.

Would be nice to hear from you.

Regards, Danny

Hey Danny,

When 5.12 released I posted on Bluesky a post that v5.12 could be the last version or something like that. I got questions about that and will repeat the answer that I wrote back then here (as it's in a helpdesk thread)

"How LLBLGen Pro is today, it's basically feature complete. There are always things to add of course, but in its core it can do what you need. So adding new features requires a need for them to be there, and to be honest I don't see much of these left out.

Not adding new features doesn't mean I'll abandon it. It means that versions with new features will likely not happen or perhaps only will have very few new features (like a new .net / ef core version support)... What won't happen is adding new concepts, which are big features like what we added some time ago with the DTO frameworks; these concepts as I call them require features being added across the board, in the designer, perhaps in the drivers for obtaining new sets of meta-data, perhaps runtime support...

We'll keep supporting the users who require support, and the last thing I want is to leave the people who have used and use our software over the years in the cold. We've debated what to do after 5.12, like just stop with it 100% and what to do with customers who have a valid license: and we've decided to keep going what we've done for the past few years, which is support the people who want support, and we'll see where it goes, as there are still a (small) group of customers. And if it stops entirely... the one thing that's not available in source form to you, which is the designer and its assemblies, will be opened to you, so users can continue using it if they want to and adjust it if they need. In what form will be decided if the time comes.

This might all sound dramatic but it's not that bad. The main thing: no more releases with new features, isn't the end of the world: how the system is today, it will keep on working; the framework runs on .net 9+, the designer can deal with those, it can obtain meta data from the main databases it supports and it can produce code working with the newest IDEs and project formats. Of course it doesn't utilize the latest C# syntax but other than that, it works fine. It's databases, they have a core that's 20+ years old that will keep on working. "

After that we've released 5.13 which got a few new things and support for new .NET platforms, fixes for breaking changes in .net 10 etc. but nothing earth shattering. I think that's going to be the future from now on: yearly new releases with a couple of things that are nice to have but nothing earth shattering or big, coupled with support for the latest .NET framework and EF Core version.

Future of LLBLGen by DvK

DvK — Sat, 18 Jul 2026 16:11:05 GMT

Hi,

Just curious about what new things or implementation of new database-engine features are up for LLBLGen? It's still a very solid ORM which has a place in the current landscape of modern application development.

Would be nice to hear from you.

Regards, Danny

Run element search queries from the CLI by jovball

jovball — Mon, 22 Jun 2026 18:54:12 GMT

I didn't know about that plug-in approach. Let me take a look at that next.

The auto-add is not an option for the reason you stated.

Run element search queries from the CLI by Otis

Otis — Mon, 22 Jun 2026 08:10:36 GMT

The refresh cycle can automatically reverse engineer entities from newly found tables/views. Set "Add new elements after relational model data sync" to true, and the CliRefresher will automatically map new elements to not-mapped elements in the catalog. Of course, if you have elements in your catalog you don't want to map, then this isn't the right approach. (as those elements will end up as an entity ... )

The scripts you'd like to run prior to code generation, you can also put these in a simple plugin dll and run these prior to code generation based on designer events. This is the preferred way, as you then can also block the code generation process if things aren't the way they should. Did you look into these options and if so, what made you think not to pursue that route?

Run element search queries from the CLI by jovball

jovball — Sun, 21 Jun 2026 20:24:06 GMT

Honestly, it's a safety net so I have one less thing that I can forget. We are using dbschema as a db comparison/scripting tool and we treat that as the source of truth for the database.

The workflow process is built around a custom console app.

Run the build to validate we don't have compilation errors
Refresh dbschema from the db
Read the LLBLGen XML and lists any tables/views that are in dbschema but not entities in LLBLGen. That's my cue to add the entity that I forgot to reverse engineer.
Call the LLBLGen cli code generator. This is where I'd like to run those search queries and save before the code gen.
Stages the git changes from the code gen
Run the build to validate we don't have compilation errors

Right now, the Id issues don't surface until runtime which is annoying.

While I'm dreaming about CLI functionality, it would be awesome if I could add tables/views to the Catalog and automatically reverse engineer them to entities. It would need to use default naming/grouping behavior in that situation. But, that was not my original request.

Run element search queries from the CLI by Otis

Otis — Sun, 21 Jun 2026 07:04:02 GMT

We'll see what we can do with the next version. Tho, currently we have only 2 CLI tools: refresher and code generator. Both aren't really suitable to add this to, so not sure how we'll do this... These actions run as part of the code generation cycle? As in: how / when would you do these in the current setup?

Run element search queries from the CLI by jovball

jovball — Sat, 20 Jun 2026 13:50:06 GMT

I have some useful element search queries that are a standard part of our workflow. For example, rename the identifying field to Id because that's what EF Core wants and remove the read-only flag on Identity columns because that's what OData requires.

It would be great if I could run those from the CLI.

JSON/Vector data type support for SQL Server 2025 by Otis

Otis — Wed, 18 Mar 2026 08:19:34 GMT

DvK wrote:

OK, that's a pity. I thought EF Core supports it, so LLBLGen will as well.

IIRC EF Core supports json types indeed, don't think they support vector (yet). A long time ago we decided not to add xpath, json and the like types unless it's possible to query them with parameters, but no database has implemented it that way, so we don't support them in our runtime.

JSON/Vector data type support for SQL Server 2025 by DvK

DvK — Wed, 18 Mar 2026 07:50:16 GMT

OK, that's a pity. I thought EF Core supports it, so LLBLGen will as well.

JSON/Vector data type support for SQL Server 2025 by Otis

Otis — Wed, 18 Mar 2026 07:14:51 GMT

We don't support json types because querying requires the predicate to be embedded into the sql string (same reason as with xpath) . For vector types, we have to think about it, but I doubt we'll do it.