Designer Preferences

The LLBLGen Pro designer is controllable through various preferences. These preferences are editable through the Designer Preferences Editor. The meaning of each preference setting is described below. Each preference is listed in the same group as it is listed in the Designer Preference Editor. It's highly recommended you examine the various preferences before you create a new project as a new project inherits many of the preferences available.

Catalog Refresher

• Add new elements after refresh When set to true, any new entities, typed views and stored procedures are added to the project automatically after a catalog refresh has been completed
• Add new fields after refresh When set to true (default), any newly found, unmapped field in an entity's target, which hasn't been removed previously from the entity, is added as a new entity field to the Entity automatically after a catalog refresh has been completed, except if the entity is in a TargetPerEntityHierarchy hierarchy and not the root of the hierarchy. If the entity is in a TargetPerEntityHierarchy hierarchy and the new target field is not nullable, it's added to the root entity only, if this setting is set to true.
• Add new views as entities after refresh When set to true, for each new view found in the catalog(s) a new entity will be added to the project automatically, after a catalog refresh has been completed. Default is false. This option is ignored if AddNewElementsAfterRefresh has been set to false as well.
• Create backup before refresh When set to true, LLBLGen Pro will backup your current project before refreshing any catalogs. This is the default and recommended setting.
• Driver command timeout The value of this setting controls the timeout value of the ADO.NET commands used to retrieve relational model data from the database when a project is created or when a catalog is refreshed. Specified in seconds. Not used with Firebird as Firebird doesn't support command timeouts.
• Identifying fields follow DB primary key constraints When set to true (Default), all identifying fields in entities have to have a target field which is also a primary key in the new relational model data after refresh, or they'll be cleared from being identifying fields. When set to false, identifying fields without a primary key field as target in the new relational model data are left as-is and there aren't any fields marked as identifying fields based on primary key fields found in the new relational model data.
• Length precision scale follow DB length precision scale When set to true (Default), a model field / parameter will have its type parameters max length, precision and scale synced with the target it is mapped on (ValueType contained fields are not updated, as they can have more than one target). When set to false, it will leave the model field / parameter type information as-is, which could cause validation errors.
• Relationships follow DB foreign key constraints When set to true (Default), all normal relationships which are not marked as 'model-only' have to have a foreign key constraint in the new relational model data after refresh, or they'll be removed. When set to true, new relationships are created from newly found foreign key constraints. When set to false, relationships without a foreign key constraint in the new relational model data are left as-is and there aren't any new relationships created from foreign key constraints found in the new relational model data.
• Remove unmapped elements after refresh When set to true, any element which doesn't have a mapping after a catalog refresh is removed from the project. Default is false.
• Reset field order based on target order at refresh. This setting, false by default, when true, resets all field indexes to the target ordinal after a catalog refresh. A new project inherits the preference value.
• Show report after refresh When set to true, the refresher will show a report after the refresh has been completed with the changes it could detect. It's recommended to have this option set to true.
• Sync mapped element names after refresh When set to true, LLBLGen Pro will rename any entity, navigator, typed view, entity field and typed view field if the name of the element they're mapped on has changed, for example a table field was renamed. Setting this option to true can break your own code, so use this option with care. When SyncRenamedMappedElementNamesAfterRefresh is set to false, only non-manually changed element names are synced, otherwise all element names are synced.
• Sync renamed mapped element names after refresh When set to true (default: false), LLBLGen Pro will sync manually renamed elements after a refresh if SyncMappedElementNamesAfterRefresh is set to true and the name of the element they're mapped on has changed. If SyncMappedElementNamesAfterRefresh is set to false, this setting is ignored. Multiple entities mapped onto the same target will all be resynced in case of a target name change, so use this setting with care.
• Unique constraints follow DB unique constraints When set to true (Default), all unique constraints in entities have to have a unique constraint in the new relational model data after refresh, or they'll be removed. When set to true, new unique constraints are created from newly found unique constraints. When set to false, unique constraints without a unique constraint in the new relational model data are left as-is and there aren't any new unique constraints created from unique constraints in the new relational model data.
• Update custom properties after refresh When set to true, any custom property in an entity, entity field, typed view, typed view field or stored procedure will be updated with a similar named custom property in the newly catalog information, after a refresh of the catalog(s). Setting this option to true can break your own code, so use this option with care. If you have set RetrieveDBCustomProperties to false, this option has no effect.

Designer behavior

• Additional plugins folder The additional plug-ins folder to load plug-ins from. This is an absolute path
• Additional tasks folder The additional tasks folder to load tasks and related files from. This is an absolute path. The designer will search this folder for *.tasks/*.platform/*.presets files
• Additional templates folder The additional templates folder to load templates from. This is an absolute path. The designer will search this folder for templateGroups.config/*.language/*.templatebindings/*.frameworksettings files
• Auto assign sequences to integer pks When set to true (default), the designer will for every auto-mapping action try to assign a sequence to every integer typed identifying field, if the identifying field is the only field for the entity, it's not a foreign key field and not inherited. If no sequence could be found and the target database supports user sequences, a new sequence will be created, using SequencePattern. A new project will inherit this value.
• Auto assign type converter to field mapping When set to true, the Type Conversion Definitions in the project are searched for a matching Type Converter for the mapping of a field and if found the Type Converter is assigned automatically to the field's mapping. Used during reverse engineering, relational model data refresh, forward mapping to new fields and forward mapping to existing fields. Default is false. A new project will inherit this value.
• Changed element back color When an entity, typed list, typed view or stored procedure call definition is changed, its node's back color in the project explorer will change color to the color set as ChangedElementBackColor.
• Changed element fore color When an entity, typed list, typed view or stored procedure call definition is changed, its node's text color in the project explorer will change color to the color set as ChangedElementForeColor.
• Confirm designer close When set to true, the user has to confirm a closure of the LLBLGen Pro designer
• Create backup before import. Similar to CreateBackupBeforeRefresh. True by default, it creates a backup before the user imports data into the actual project, as importing a model is non-undoable. The backup makes it possible to revert to a project state before the import action.
• Create backup before running plugin When set to true (default), a backup of the current project is created before you run a plugin. It is recommended you leave this setting set to true.
• Default backup folder The default backup folder in which LLBLGen Pro will create backups of the project loaded, for example before when a refresh is performed. Specify the folder with full path or if you want to make the path relative to the project location, specify the path as a relative path. A relative path starts with '.\' or with '..\' (without the quotes). If you leave this preference empty, the default, the folder the project file is located in, is used.
• Default relationship delete rule action. This setting controls the default value for the Delete Rule Action for new relationships. Update Rule and Delete Rule are used for cascade settings on the backing foreign key constraint (if applicable). Default: Cascade. In project settings, this setting is available under Model First development.
• Default relationship update rule action. This setting controls the default value for the Update Rule Action for new relationships. Update Rule and Delete Rule are used for cascade settings on the backing foreign key constraint (if applicable). Default: NoAction. In project settings, this setting is available under Model First development.
• Entity action combination default for table. The default action combination for an entity mapping if the mapping target is a table. Default is CreateRetrieveUpdateDelete. Not all supported target frameworks support all available values. Please consult the LLBLGen Pro documentation on the used target framework for the supported values of that framework regarding table targets. If a framework doesn't support a value, it's ignored. A new project will inherit this value.
• Entity action combination default for view. The default action combination for an entity mapping if the mapping target is a view. Default is Retrieve. Not all supported target frameworks support all available values. Please consult the LLBLGen Pro documentation on the used target framework for the supported values of that framework regarding table targets. If a framework doesn't support a value, it's ignored. A new project will inherit this value.
• Expand group nodes on project load. True by default. When set to false, group nodes are not expanded in the project explorer after  the project has been loaded.
• Group usage This setting controls how the grouping functionality of the designer is used with respect to the generated output: solely as visual grouping construct (default) (so all elements in the entire project are seen as one project) or as separate projects (one per group). If you choose to see groups as separate projects, validation will verify that there are no ties between groups whatsoever and will report errors if there are. If you choose to see groups as a visual grouping construct only, validation will verify if there are duplicate named elements among groups and will report errors if there are. A new project will inherit this value.
• Hide foreign key fields in editor When set to true, the designer will hide foreign key fields in field editors using a filter (which is editable). When set to false (default) all fields are shown by default in the field editors.
• Project explorer open element on double click When set to true, double-clicking an element node (entity / typed list / typed view / stored procedure call) will also open the element in its editor. The element's node is also expanded/collapsed. When set to false, double-clicking a node in the tree will just expand/collapse the node.
• Search query default language The .NET language to pre-select in the Element Search dialog.
• Sync relational model data element name after rename When set to true, the designer will automatically synchronize a table name or table field name with its mapped project element if the project element is manually renamed in the designer. Default is false.
• Target per entity edges require backing fk constraint. If true (default), the designer will require that every inheritance edge between a subtype and a supertype in a hierachy of type TargetPerEntity has a backing foreign key constraint in the relational model data (if supertype and subtype are mapped both mapped onto tables in the same catalog). Only set this to false in the situation when you need to define a TPE hierarchy and can't add new foreign key constraints. A new project inherits this value.
• Use custom field ordering on new elements. False by default. If true, it will set the FieldIndexes of the fields created through reverse engineering and when fields are added to a new entity through model-first functionality. This setting can help in a DB first scenario when ordinals on target tables have to be used to guide field ordering, and when new entities are created in the designer and fields have to have a given order from the start. A new project inherits this value.
• Verbose application output When set to true, the application output window's verbose setting will be set to true at application startup.

Name construction

• Enforce pascal casing always When set to true, the setting 'MakeElementNamePascalCasing' is enforced always. When set to false, the setting 'MakeElementNamePascalCasing' is enforced only when names for new elements are created. A new project will inherit this value
• Make element name pascal casing When set to true, all names of new entities, entity fields, typed views etc. will be properly PasCal cased. This means that each character in the name is lowercased, except the first character after each word boundary ('_' or ' ') and the first character. All spaces are always removed. When set to false, the name is left untouched, except for the first character, which will always be UpperCase. A new project will inherit this value.
• Remove underscores from element name When set to true, all single underscores in names of new entities, entity fields, typed views etc. will be removed. When set to false, the name is left untouched. A new project will inherit this value.

Name construction, Name patterns

• Field mapped onto related field pattern The pattern which is used to construct the names for Fields mapped onto a related field. Pattern elements can be: {$RelatedEntityName} for the name of the related entity which contains the mapped related field and {$RelatedFieldName} for the name of the field in the related entity which is mapped by the field mapped onto a related field. You can also specify any literal text. An element can be mentioned more than once. A new project will inherit this value
• Foreign key field pattern The pattern which is used to construct the names for Foreign Key fields in entities. Pattern elements can be: {$NavigatorName} for the navigator name mapped onto the relationship used, {$RelatedFieldName} for the field referred to by the foreign key field (the PK field) and {$RelatedEntityName} for the name of the related entity (the PK side). You can also specify any literal text. An element can be mentioned more than once. A new project will inherit this value.
• Navigator mapped onto many to many pattern The pattern which is used to construct the names for Navigators mapped on m:n relationships. Pattern elements can be: {$StartEntityName} for the name of the start entity, {$EndEntityName} for the name of the end entity, {$IntermediateEntityName} for the name of the intermediate entity, $P or $S suffix to entity name macros to pluralize or singularize them (example: {$EndEntityName$P}), {$StartEntityFieldNames} for all the names of the fields of the relationship in start entity, {$EndEntityFieldNames} for all the names of the fields of the relationship in the end entity and any literal text. An element can be mentioned more than once. A new project will inherit this value.
• Navigator mapped onto one many to one pattern The pattern which is used to construct the names for Navigators mapped on m:1 or 1:1 relationships. Pattern elements can be: {$StartEntityName} for the name of the start entity, {$EndEntityName} for the name of the end entity, $P or $S suffix to entity name macros to pluralize or singularize them (example: {$EndEntityName$P}), {$StartEntityFieldNames} for all the names of the fields of the relationship in start entity, {$EndEntityFieldNames} for all the names of the fields of the relationship in the end entity and any literal text. An element can be mentioned more than once. A new project will inherit this value
• Navigator mapped onto one to many pattern The pattern which is used to construct the names for Navigators mapped on 1:n relationships. Pattern elements can be: {$StartEntityName} for the name of the start entity, {$EndEntityName} for the name of the end entity, $P or $S suffix to entity name macros to pluralize or singularize them (example: {$EndEntityName$P}), {$StartEntityFieldNames} for all the names of the fields of the relationship in start entity, {$EndEntityFieldNames} for all the names of the fields of the relationship in the end entity and any literal text. An element can be mentioned more than once. A new project will inherit this value.
• Typed view mapped on resultset pattern. This pattern is used to create the typedview name when it's been reverse engineered and it's mapped onto a resultset of a stored proc or tvf. Marco elements: {$ResultsetName} and {$ProcFunctionName}. Default: {$ProcFunctioName}{$ResultsetName}TypedView. {$ResultsetName} is ignored if the procedure or function has just one resultset. A new project will inherit this value.

Name construction, Strip patterns

• Entity field name strip pattern The pattern which contains two sections, enclosed in {}, one for the prefixes and one for the suffixes. Add prefixes and suffixes to strip off by separating them by a comma. The first match is stripped. If the entity field's name is equal to a prefix/suffix strip pattern, nothing is stripped off. Stripping is case insensitive. A new project will inherit this value.
• Entity name strip pattern The pattern which contains two sections, enclosed in {}, one for the prefixes and one for the suffixes. Add prefixes and suffixes to strip off by separating them by a comma. The first match is stripped. If the entity's name is equal to a prefix/suffix strip pattern, nothing is stripped off. Stripping is case insensitive. A new project will inherit this value. Example: prefix strip pattern tbl_ and suffix strip pattern _dev will form the strip pattern {tbl_}{_dev}.
• Stored proc name strip pattern The pattern which contains two sections, enclosed in {}, one for the prefixes and one for the suffixes. Add prefixes and suffixes to strip off by separating them by a comma. The first match is stripped. If the stored procedure's name is equal to a prefix/suffix strip pattern, nothing is stripped off. Stripping is case insensitive. A new project will inherit this value. Example: prefix strip patterns pr_ and sp_ and suffix strip pattern _dev will form the strip pattern {pr_, sp_}{_dev}.
• Table valued function name strip pattern. This pattern is similar to the stored proc name strip pattern, except it's now used for constructing TvfCall names.
• Typed view field name strip pattern The pattern which contains two sections, enclosed in {}, one for the prefixes and one for the suffixes. Add prefixes and suffixes to strip off by separating them by a comma. The first match is stripped. If the typed view field's name is equal to a prefix/suffix strip pattern, nothing is stripped off. Stripping is case insensitive. A new project will inherit this value.
• Typed view name strip pattern The pattern which contains two sections, enclosed in {}, one for the prefixes and one for the suffixes. Add prefixes and suffixes to strip off by separating them by a comma. The first match is stripped. If the typed view's name is equal to a prefix/suffix strip pattern, nothing is stripped off. Stripping is case insensitive. A new project will inherit this value. Example: prefix strip pattern vw_ and suffix strip pattern _dev will form the strip pattern {vw_}{_dev}.

Relational model data element construction

• Insert underscore at word break case sensitive DBs When a new table or table field has to be constructed based on a project element (entity, field, typed view), or when the project element is manually renamed and SyncRelationalModelDataElementNameAfterRename is set to true, the name for the element is based on the project element name using this setting. Ignored on case-insensitive databases. When set to true, an underscore is inserted at word breaks. Default is false. A new project will inherit this value.
• Prefer decimal over currency types When set to true (default), the designer will, when creating a relational model data field element, prefer the decimal type (if present / supported) over currency / money types (if present / supported), when more than one database type matches the model element's .NET type.. When set to false, currency / money types are prefered. A new project will inherit this value
• Prefer natural character types When set to true (default), the designer will, when creating a relational model data field element, prefer natural character database types (e.g. nvarchar, nchar) over normal character database types (e.g. char, varchar), when more than one database type matches the model element's .NET type.. When set to false, normal character database types are prefered. A new project will inherit this value
• Prefer system sequences over schema sequences if applicable When set to true (default), the designer will choose system sequences for identity fields instead of creating new / picking existing schema sequences, if schema sequences are supported by the database type. If the database type only supports one type of sequence, that type is chosen regardless of the value of this setting. A new project will inherit this value.
• Prefer variable length types When set to true (default), the designer will, when creating a relational model data field element, prefer variable length database types (e.g. varchar, varbinary) over fixed length database types (e.g. char, binary), when more than one database type matches the model element's .NET type. When set to false, fixed length database types are prefered. A new project will inherit this value
• Relational model data element name casing case sensitive DBs When a new table or table field has to be constructed based on a project element (entity, field, typed view), or when the project element is manually renamed and SyncRelationalModelDataElementNameAfterRename is set to true, the name for the element is based on the project element name using this setting. Ignored on case-insensitive databases. AllUpperCase means all characters are upper-cased. AllLowerCase means all characters are lower-cased, AsProjectElement will use the name of the project element as-is. A new project will inherit this value.
• Set schema name after group name. If true (default), an automatically created table will have its schema name set after the group name the entity is in. Otherwise the schema name will be set to the default schema name. A new project inherits this value.
• Show report after auto map When set to true (default), the designer will show a report after the Auto-map of unmapped entities/unmapped entity fields features have been executed.

Relational model data element construction, Name patterns

• Foreign key constraint pattern. The pattern which is used to construct the names for foreign key constraint objects in the relational model data. Pattern elements can be: {$TableName} for the name of the table the foreign key constraint is part of, {$Guid} for a guid value, to ensure a unique name, {$FieldNames} for the names of the table fields, in ordinal order, which form the foreign key, {$PkTableName} for the name of the primary key side table in the foreign key constraint. You can also specify any literal text. An element can be mentioned more than once. A new project will inherit this value
• Primary key constraint pattern. The pattern which is used to construct the names for primary key constraint objects in the relational model data. Pattern elements can be: {$TableName} for the name of the table the primary key constraint is part of, {$Guid} for a guid value to ensure a unique name, {$FieldNames} for the names of the table fields, in ordinal order, which are part of the primary key constraint. You can also specify any literal text. An element can be mentioned more than once. A new project will inherit this value
• Sequence pattern The pattern which is used to construct the names for sequence objects in the relational model data using auto-mapping functionality. Pattern elements can be: {$EntityName} for the name of the entity containing the identifying field which is sequenced and {$FieldName} for the name of the field which is sequenced. You can also specify any literal text. An element can be mentioned more than once. A new project will inherit this value
• Unique constraint pattern. The pattern which is used to construct the names for unique constraint objects in the relational model data. Pattern elements can be: {$TableName} for the name of the table the unique constraint is part of, {$Guid} for a guid value to ensure a unique name, {$FieldNames} for the names of the table fields, in ordinal order, which are part of the unique constraint. You can also specify any literal text. An element can be mentioned more than once. A new project will inherit this value

Reverse Engineering

• Auto add many to many relationships When set to true, the designer will automatically add new m:n relationships it detects during the reverse engineering process of entities from relational model data. Default is false. A new project will inherit this value.
• Fk fields are named after target field When set to true (default), the name of a foreign key field in an entity created through reverse engineering, is created from the target field of the foreign key field. When set to false, the ForeignKeyFieldPattern is used to construct the name for the foreign key field. A new project will inherit this value.
• Retrieve DB custom properties When set to true, all custom property data of the database objects a new project object is based on will be copied to the object's Custom Properties. A new project will inherit this value
• Sequence name matching pattern. The pattern which is used to find a sequence for a numeric primary key field which is being reverse engineered to an entity field. The pattern is used to construct the name of the sequence to find. Pattern elements can be: {$TableName} for the name of the table the field is in and {$FieldName} for the name of the field which is sequenced. You can also specify any literal text. An element can be mentioned more than once. A new project will inherit this value.
• Set group name after schema name When set to true (default), the designer will automatically set the group name of new elements to the name of the schema the target element is located in. If the target database has a default schema name (e.g. 'dbo'), the default schema name is converted to the empty string for the group name. If the target database doesn't use schemas, this setting is ignored. A new project will inherit this value.
• Singularize element names When set to true (default), the name for a new model element which is derived from the relational model element (e.g. table) it is reverse engineered from, is singularized. Example: a new entity reverse engineered from the table 'customers' will be called 'customer'. A new project will inherit this value.

Task performers, General

• Always load lpt source code When set to true, after each code generation cycle, the .lpt template runner sourcecode (if any) is opened in the text editor. The sourcecode is always opened if there are errors detected during template compilation. Default is false
• Clean up vsnet projects When set to true, the VS.NET project file task performer will first remove all references to files which were generated by LLBLGen Pro from an existing VS.NET project file, before adding the files generated. Default is true. A new project will inherit this value
• Encoding to use The encoding to use for text files being written by the generator task performers. Use UTF8 if you use Visual SourceSafe, as Visual SourceSafe can't handle unicoded textfiles
• Fail code generation on write error When set to true (default is false), the code generator engines of LLBLGen Pro will throw a GeneratorAbortException to terminate the code generation cycle if a write error occurs. A write error is generated when the target file exists and is readonly and failwhenexistent is false for the executing task. A new project will inherit this value
• Preferred namespace prefix The prefix that is inserted before the initially root namespace. Typically this is your company name. You can change this in the generator configuration window. Do not include a '.' suffix.
• Show report after code generation When set to true (default), LLBLGen Pro will show the report in a modal dialog as logged by the task performers executed during code generation. The report can be copied to the clipboard, with formatting, if desired.
• Store time last generated into project When set to true (default: false), the time the last generation cycle for a project took place is stored inside the project. This will make the project 'changed' after every generation cycle, which could influence sourcecontrol behavior if you store the .llblgenproj file in a sourcecontrol system. A new project will inherit this value

Text Editor

• Text editor font The font to use in the text editor, which is used for editing template files and other text-based files opened in the designer
• Vsnet xsd folder The folder where VS.NET stores the .xsd files for intellisense on xml based files
• Word wrap When set to true, word-wrap is enabled in text editors opened in the designer. Default is false

Validation / Relational model data adjustment

• Excludable orphaned element detected action The action to perform when the system detects an 'orphaned' excludable relational model data element (element which is not a mapping target). If the specified value isn't applicable for the specific element, ExcludeFromProject is used instead. A new project will inherit this value.
• Non excludable orphaned element detected action The action to perform when the system detects an 'orphaned' non-excludable relational model data element (element which is not a mapping target). If the specified value isn't applicable for the specific element, RaiseError is used instead. A new project will inherit this value.