LLBLGen Pro Support System Designer feed

Change entitynames and fieldnames in llblgenproj-file from Dutch to English by Otis

Otis — Fri, 16 Jan 2026 07:42:34 GMT

There's no translation service in the designer, but it does have a plugin system for you to utilize so you can access the entire object model. If you look at the Sourcecode archive (available in the Extras section of a version's download page), there's a plugins folder which has a C# project. It has a couple of plugins in sourcecode to illustrate how to create a simple plugin.

The designer ships with a plugin called 'Project inspector'. You can start it by right-clicking on the project node in the project explorer -> Run plugin -> Project inspector. It basically lists the entire object model represented by the project. It's a visual way for you to navigate the object model so you can easily find what to change in your plugin.

E.g. to iterate over all the entities, enumerate the EntityModel.Vertices collection. Additionally, the Project has an API, which is documented in the reference manual here: https://www.llblgen.com/Documentation/5.13/ReferenceManuals/Designer/html/727B4215.htm. As the designer uses an undo / redo system, it's probably the easiest to wrap the entire process in an UndoablePeriodCommand. This is a command that can undo/redo everything in 1 go. As the designer is using an event system to keep everything in sync, changing something will cause a ripple effect of changed events at times. This isn't noticeable other than in the project explorer which is repainted a lot because of that. So it's crucial if you go the plugin route to make sure the plugin description states the project explorer has to be reset (See the sdk doc page linked above).

To do that, use:

var cmd = new UndoablePeriodCommand();

CommandQueueManagerSingleton.GetInstance().BeginUndoablePeriod(cmd);

// do work

CommandQueueManagerSingleton.GetInstance().EndUndoablePeriod(cmd);

You can also switch off the undo/redo system temporarily to speed things up by using: CommandQueueManagerSingleton.GetInstance().BeginNonUndoablePeriod() and ending it with CommandQueueManagerSingleton.GetInstance().EndNonUndoablePeriod().

If you want to do this in a CLI tool, you can, you then should look at one of the two CLI tools we ship in sourcecode form: the CLI refresher and the CLI generator. Both load the project and from there you can access it and do what you want with it, and as there's no designer active, there's no undo/redo system live as well.

Renaming is a matter of setting the Name property of a new value. This won't ripple through to relationships however. You have to iterate over these yourself and set the navigator names manually. The relationships in the model are the Edges collection of the EntityModel mentioned earlier. I'd first rename all entities, then all fields of each entity, then the relationships and then the Forfs. You don't have to touch mappings or tables.

To construct new names based on the patterns defined in the project, you can utilize the methods CoreUtils.MakeCLSCompliantName, CoreUtils.MakeUniqueName, ApplicationUtils.CreateUniqueElementName, ApplicationUtils.CreateNavigatorNamesand there are some more you can utilize, see the reference manual for details.

E.g. this is how the (sadly, internal) method RelationshipEdge.ProduceUniqueNavigatorNames() produces unique names in the reverse engineering process:

string startNavigator;
string endNavigator;
ApplicationUtils.CreateNavigatorNames(this, containingProject.Properties, out startNavigator, out endNavigator);
startNavigator = CoreUtils.MakeUniqueName(new FieldNameValidator(this.StartVertex, containingProject) 
                                                { AdditionalNavigatorsToCheck = additionalNavigatorsStartEntity }, startNavigator);
endNavigator = CoreUtils.MakeUniqueName(new FieldNameValidator(this.EndVertex, containingProject) 
                                                { AdditionalNavigatorsToCheck = additionalNavigatorsEndEntity }, endNavigator);

Then you have to set the NavigatorName property on the Navigator objects of the relationship.

To test things out, you can also use the C# repl inside the designer, in the Element Search window You can write any C# there in the query pane and do whatever you want to the project elements, and it'll run that as long as you e.g. return the expected object.

Veel succes!

Change entitynames and fieldnames in llblgenproj-file from Dutch to English by SanderF

SanderF — Thu, 15 Jan 2026 14:02:16 GMT

We currently have approximately 500 entities with approximately 12,000 fields mapped in the LLBLGen designer. We intend to change the names of the entities and fields from Dutch to English. Is there a tool available within LLBLGen to do this? We're working on a PowerShell script that does this based on an Excel sheet with translations and manipulating the .llblgenproj-file, but we're running into several issues, such as relationships and forfs where names are sometimes separated by a :. This makes the conversion difficult.

Designer configure UseSqlOutputClause (EF) by Otis

Otis — Tue, 09 Dec 2025 08:46:06 GMT

We've added a project level setting and an entity level setting to control this in 5.13 which we hope to ship in beta before xmas.

Designer configure UseSqlOutputClause (EF) by Otis

Otis — Sun, 05 Oct 2025 06:29:48 GMT

This is possible, you can define a new templatebindings file with the binding for ModelBuilder.lpt, which is using the SD_EF_Core_ModelBuilder templateID, and bind it to a different file. Then when defining the code generation task (F7 -> double click the task), specify the templatebindings file with your binding above the existing one in the templatebindings tab that's visualized when you click 'Advanced' button.

More info about templatebindings: https://www.llblgen.com/Documentation/5.12/Designer/Functionality%20Reference/TemplateBindingsViewer.htm and https://www.llblgen.com/Documentation/5.12/SDK/templates_templatesystem.htm#templatebindings-files-xml-format

This way you use an alternative version of the modelbuilder template during code generation, basically overriding the existing one shipped with the designer.

An alternative could be to generate derived class for the model builder using a new template (which thus requires a new .lpt file and template bindings file and a new task added to the preset you're using, see e.g. https://www.llblgen.com/Documentation/5.12/Designer/How%20To/TemplatesAdd.htm), and override the Map* methods for the entities which have fields with this setting, then first call the base method and then alter the properties which need this clause set. This might be a better solution as you don't have to keep track of existing templates if they might get updated (so you then have to migrate those changes to your copy e.g. the copy of the ModelBuilder.lpt with your own changes)

Designer configure UseSqlOutputClause (EF) by AndreasIsWorking

AndreasIsWorking — Fri, 03 Oct 2025 08:19:53 GMT

Hi,

To make this easier for my team and ensure consistency across environments, I’d like to move the updated ModelBuilder file to a relative folder in our repository

(making use of the Additional Templates Folder in project settings?)

(e.g. /llblgen-templates/ModelBuilder/) and configure LLBLGen to generate code using that version of the file instead of the default one.

Is there a supported way to override the default location of the ModelBuilder file or bind it to a custom path within the project settings?

Designer configure UseSqlOutputClause (EF) by AndreasIsWorking

AndreasIsWorking — Fri, 03 Oct 2025 07:08:03 GMT

LLBLGen Pro version: 5.12 (5.12.1) RTM

.NET version: 8.0

Database: SQL Server 2017

Hi,

I'm currently customizing the ModelBuilder template to conditionally apply .UseSqlOutputClause(false) during inserts in EF Core, based on a custom property (UseSqlOutputClause) defined in OutputSettingValues.CustomProperties.

This helps us avoid issues with triggers and constraints in our database setup.

At the moment, I'm manually updating the generated ModelBuilder file in the LLBLGen application programs folder after each code generation run.

I'm not sure if LLBLGen already provides a built-in way to configure this behavior through the designer or metadata—if it does, I'd love to know how to use it.

If not, would it be possible to consider adding support for this in a future version, either as a per-entity setting or a global option?

Thanks in advance for your help!

Andreas

what i would like to achieve:

protected virtual void MapAddressEntity(EntityTypeBuilder<AddressEntity> config)
{
    config.ToTable("Address", tb => tb.UseSqlOutputClause(false));
}

how i currently fixed it: (modelbuilder.lpt)

        protected virtual void Map<%=entity.Name%>(EntityTypeBuilder<<%=entity.Name%>> config)
        {
            <% var useSqlOutput = false;
            if(entity.OutputSettingValues.CustomProperties.ContainsKey("UseSqlOutputClause"))
            {
                useSqlOutput = entity.OutputSettingValues.CustomProperties["UseSqlOutputClause"].ToString().ToLower() == "true";
            }
            %>config.ToTable("<%=mapping.MappedTarget.Name%>"<%
                if(mapping.MappedTarget.ContainingSchema.SchemaOwner!=defaultSchema) { %>, "<%=mapping.MappedTarget.ContainingSchema.SchemaOwner%>"<% } 
                if(supportsTemporalTables && targetIsTemporalTable) { %>, b=>b.IsTemporal(b=> { b.HasPeriodStart("<%=periodStartField.FieldName%>"); b.HasPeriodEnd("<%=periodEndField.FieldName%>");})<%}
                if(!string.IsNullOrEmpty(tptDifferentPkTargetNames)) { %>, <%=tptDifferentPkTargetNames%><% } 
                if(useSqlOutput) { %>, tb => tb.UseSqlOutputClause(false)<% } 
                %>);

...

Migrate to SDK-Style Project File by Otis

Otis — Tue, 16 Sep 2025 07:26:40 GMT

The designer won't overwrite a csproj file if it already exists. So you can do two things: use the netstandard2.0 preset and alter the generated csproj file to use netframework instead of netstandard20, or alter the net4.8 preset and specify the templateid for the netstandard20 vsproj template instead of the one that's currently specified. You can edit the preset files right in the designer, and e.g. save it under your own name.

In our unittests we use multitargeting and have altered the csproj files to multitarget both net452 and netstandard, then we generate the codebase using netstandard. You'll miss some files that way tho:

the AssemblyFileInfo classes, which are onetime generated anyway so it's not a big deal .
the webserviceHelperClass which is likely not needed if you don't do webservices the old way
the webservice schema importer which is also unlikely you'll need it.

Generating the code base again leaves the csproj files as-is because as I said the designer won't overwrite them

Migrate to SDK-Style Project File by coachpotato

coachpotato — Mon, 15 Sep 2025 09:41:11 GMT

LLBLGen 5.11.5

SelfServicing (General)

SQL Server 2017

.NET Framework 4.7.2

We busy migrating to SQL Server 2022 (Azure SQL Managed Instance) and .NET Framework 4.8 (and eventually to newer .NET).

Is there a way to set the designer to generate the project file using the new SDK-style format, and not the old verbose clunky format?

Or is that only for .NET Standard 2.0+?

"Migrate packages.config to PackageReference" and "Upgrade" -> "Convert project to SDK-style" for all the solution projects (non ASP.NET) and libraries was very easy.

Wondering if there is an easy way to set it in the Designer, or if I would need to convert it every time we regenerate the Data project, or if we need to upgrade to .NET Standard (which might have it's own issues?) and update all the other projects and libraries (sigh!).

Assigned type of field in designer is not emitted in the generated code although the field has a type shortcut assignment by Otis

Otis — Wed, 07 May 2025 07:16:29 GMT

Yes it’s possible. What the designer needs are just types, it doesn’t use them as in: the functionality in methods in the type aren’t important, so if you have a .net framework dll with types with the same names, it’ll emit the right type names in the generated code. The typeconverters for the designer the instantiate an instance of your types for the designer and it should work ok.

Assigned type of field in designer is not emitted in the generated code although the field has a type shortcut assignment by nasser_colliers

nasser_colliers — Tue, 06 May 2025 17:13:08 GMT

Thank you for your reply and the links!

In the documentation you mentioned (https://www.llblgen.com/Documentation/5.12/Designer/Functionality%20Reference/SystemTypeConverters.htm), it appears as though I must create my types, as well as type converters in dotnet full framework (> 4.5.2).

Now the types I'm required to emit as ids are created using this library: https://github.com/andrewlock/StronglyTypedId/. This is a pure dotnet core library, and we cannot use it in full framework. This means, that all the type converters and the generated types for the IDs will be generated using dotnet core. Does this mean that I cannot read these types and their converters into LLBLGen?

Best