Project Settings

Each project has its own set of settings. These settings are called Project Settings, and are editable through the Project Settings Editor. The meaning of each setting is described below. Each setting is listed in the same group as it is listed in the Project Settings Editor.

It's highly recommended you examine the various project settings right after you have created a new project, as they control the behavior of the various features of the designer when operating on various project elements.

When a new project is created, it inherits most of its setting values from the New Project Defaults: all project settings which are also mentioned in the list of settings under New Project Defaults in Designer Preferences are inheriting their initial value from the New Project Defaults value.

Important!

In versions prior to v5.0 the Designer Preferences in the designer contained values which were used in the Project Settings as well, if their equivalent in the Project Settings was set to the value Default. Most of the catalog refresher settings were of this type as well as some model first settings.

These settings all have been converted to regular bool settings in the project settings and no longer rely on the preference value. When a project is loaded which is saved by a previous version of llblgen pro the values in the project are set after the preferences value like they would be in-effect during the previous versions.

Per setting group, reflected as a node in the left tree of the Project Settings Editor, the settings are described in more detail below. To open the Project Settings Editor, load an LLBLGen Pro project, and use the menu option Project -> Settings, or right-click the Project node in the Project Explorer and select Settings from the context menu.

General

Designer behavior

Additional task performer folder: If specified, LLBLGen Pro will look for taskperformer assemblies in this folder as well, besides the default taskperformer folder. 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 ... If you don't want to use an additional folder, leave it empty.
Additional tasks folder: If specified, LLBLGen Pro will look for *.tasks / *.platform / *.presets files in this folder as well, besides the default Tasks folder. 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 ... If you don't want to use an additional folder, leave it empty.
Additional templates folder: If specified, LLBLGen Pro will look for templateGroups.config / *.language / *.templatebindings / *.frameworksettings files in this folder as well, besides the default Templates folder and the additional templates folder defined in the LLBLGen Pro preferences. 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 ... If you don't want to use an additional folder, leave it empty.
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.

Miscellaneous

Project creator: The name of the person who created this project.
Project name: The name of the project.

Conventions: General, Code Generation, General

Task performers, General

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.
Encoding to use: The encoding to use for text files being written by the generator task performers.
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
Root namespace: The initial root namespace to use for code generation
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.

Conventions: General, Element Name Construction

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.
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.

Conventions: Entity Model, General

Additional type converter folder: If specified, LLBLGen Pro will look for assemblies with TypeConverter classes in this folder as well as .typeimports files, besides only in the default TypeConverterRootFolder folder defined in the LLBLGen Pro config file. 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 ... If you don't want to use an additional TypeConverter folder, leave it empty.
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.
Auto assign type converter to field mapping: When set to true (default), 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 synchronization, forward mapping to new fields and forward mapping to existing fields. Default is true.
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.
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.
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.
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.

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.
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.

Conventions: Entity Model, Element Name Construction

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.
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.
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.
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.
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.
Typed view mapped on resultset pattern: The pattern which is used to construct the names for typed views which are mapped onto resultsets of stored procedures or table valued functions. Pattern elements can be: {$ResultsetName} for the name of the name of the resultset {$ProcFunctionName} for the name of the stored procedure or function name returning the resultset the typed view is mapped on. {$ResultsetName} is ignored if the procedure or function has just one resultset. You can also specify any literal text. An element can be mentioned more than once.

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.
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. 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. 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.
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. Example: prefix strip pattern vw_ and suffix strip pattern _dev will form the strip pattern {vw_}{_dev}.

Abbreviations

LLBLGen Pro supports the automatic conversion of abbreviation fragments in names into full name fragments using abbreviation-full word pairs defined per project. You can specify these abbreviation-full word pairs in the 3rd tab of the Project Properties. For example a field called Addr or fields with Addr in the name can be updated with Addr being replaced with Address so CustAddr will then become CustAddress, and if Cust is also added to the abbreviations to become Customer, it will convert CustAddr into CustomerAddress.

Abbreviations are stored inside the project file so everyone using the same project file has the same abbreviations. They're simple Abbreviation - FullWord pairs and don't use regular expression syntaxis. They're matched with fragments found during name processing. Fragments are elements separated by non-usable characters, space, underscore, a full word, or where an Uppercase/Lowercase change appears. So the string AaBb_CCC Ddd has 4 fragments: Aa, Bb, CCC and Ddd.

The following rules apply:

Abbreviations are added per project, in the Project Properties Editor, and should be inserted right after the project has been created and before the entities are added to the project.
They're used during reverse engineering, when names have to be created for entities, typedviews and stored procedures, and fields for entities, typedviews and for parameters for stored procedure calls
The abbreviations are evaluated during name processing and before a FieldMappedOn*Pattern / NavigatorMappedOn*Pattern has been applied and also before casing rules have been applied.
All abbreviations are case insensitive.
Abbreviations can be used as well to specify specific casing. For example the abbreviation - full word pair: ID - ID will make sure that all ID fragments found won't be cased to Id, but will kept as ID.

It's also possible to export/import abbreviations to/from textfiles. These textfiles should have at each line the abbreviation and the full word separated by a TAB

Example:

addr    Address
cust    Customer

Conventions: Entity Model, Database First Development

Relational model data synchronization

Add new elements after relational model data sync: When set to true, any new entities, typed views and stored procedures are added to the project automatically after a relational model data synchronization task with an external database has been completed. Default is false.
Add new fields after relational model data sync: 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 relational model data synchronization task with an external database 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 relational model data sync: 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 relational model data synchronization task with an external database has been completed. Default is false. This option is ignored if AddNewElementsAfterRelationalModelDataSync has been set to false as well. Default is false.
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 a relational model data synchronization task with an external database has been completed, 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. The value Default means the value in the preferences is used.
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 a relational model data synchronization task with an external database has been completed, 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 relational model data sync: When set to true, any element which doesn't have a mapping after a relational model data synchronization task with an external database has been completed will be removed from the project. Default is false.
Reset field order based on target order at relational model data sync: If true (default is false), it will initialize the FieldIndexes of fields created through reverse engineering (database-first scenarios) and when fields are added to a new entity / valuetype (model-first scenarios). In database-first scenarios, field indexes will be set to the ordinal of the target field. In model-first scenarios, the field added will get as field index the highest existing index in the element + 1. In model-first scenarios, if there are already fields in the element and the element doesn't have any field ordering, field indexes of new fields are not set.
Sync mapped element names after relational model data sync: 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 could break your own code, so use this option with care. When SyncRenamedMappedElementNamesAfterRelationalModelDataSync is set to false, only non-manually changed element names are synced, otherwise all element names are synced.
Sync renamed mapped element names after relational model data sync: When set to true (default: false), LLBLGen Pro will sync manually renamed elements after a relational model data synchronization task with an external database has been completed if SyncMappedElementNamesAfterRelationalModelDataSync is set to true and the name of the element they're mapped on has changed. If SyncMappedElementNamesAfterRelationalModelDataSync 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 a relational model data synchronization task with an external database has been completed, 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 relational model data sync: 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 relational model data synchronization task with an external database has been completed. 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. Default is false.

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.
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 Foreign key field pattern is used to construct the name for the foreign key field.
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.
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.
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.
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.

Conventions: Entity Model, Model First Development

Designer behavior

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.
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.
Reflect nullability of element field in target field: Boolean property which makes (when true) the designer change the nullable flag on a target field based on the IsOptional value of the model field. Default is false.
Reflect type of element field in target field: When set to true (default), the designer will change the target field's type to the mapped model field's type if the types differ and no fitting TypeConverter can be assigned. If true, it will also sync length/precision/scale values, if there's a mismatch and no TypeConverter has been assigned.
Sync relational model data element name with model element name: When set to true, the designer will automatically synchronize a table name or table field name with its mapped project element during synchronization if the schema the table is in has its sync mode set to 'mixed' or 'model'. Default is false.

Relational model data element construction

Insert underscore at word break case insensitive dbs: Similar to the Case Sensitive variant, but is now used for case insensitive databases.
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 Sync relational model data element name after rename 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.
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.
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.
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.
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.
Relational model data element name casing case insensitive dbs: Similar to the Case Sensitive variant, but is now used for case insensitive databases.
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.
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.

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.
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.
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.
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.

When are Foreign Key Constraint / Primary Key Constraint / Unique Constraint patterns applied?

The patterns are applied when a new element is created, e.g. a new FK, PK or UC is created, and its name is determined using the patterns defined. Additionally, if a table or table field is renamed (either automatically through settings or by hand in the catalog explorer), constraints related to the element renamed are getting a new name using the pattern defined.

Example: Table B has a foreign key constraint F pointing to A and the pattern for the FK constraint name is FK_{$TableName}_{$PkTableName}. If table A is now renamed to table C, the FK constraint F is now renamed using the pattern and will get the new name FK_B_C. Changing the pattern in the project settings does not affect existing constraints, to avoid a lot of unwanted changes on existing elements.

Conventions: Entity Model, Target Framework Settings

This group shows the settings related to the target framework chosen, e.g. the settings related to the LLBLGen Pro runtime framework are located here. See for the framework specific settings the LLBLGen Pro manual for the specific target framework shipped with LLBLGen Pro.

Conventions: Entity Model, Code Generation, General

Connection string key name pattern: The pattern for the key in the generated config file under which the connection string for a target database is stored. A macro is required for this property: {$ProviderName}. This macro is replaced with the short name in the driver.config of the active driver. This way multiple connection strings can be emitted into the generated code without name clashes.

Conventions: Entity Model, Code Generation, Attributes / Additional Interfaces / Additional Namespaces

The groups Attributes, Additional Interfaces and Additional Namespaces, allow you to specify the defaults for Additional Attributes, Additional Interfaces and Additional Namespaces resp. for the various element types found in the project. These defaults are then inherited by every instance of these types.

If a rule is applied, the default is only inherited if the rule resolves to true for the particular element, otherwise the default is always inherited. At the element level you can decide (by editing the element in its own editor, on the Code gen. info tab of that element's editor) whether you want to inherit the default, ignore it for that element, or add new definitions only for that element.

For instance, this allows you to specify in the Project Settings the attribute definition Serializable for the element type 'Entity', which is then inherited by every entity definition in the project. If you don't want this attribute definition to be specified on a particular entity, you can open that entity's editor, go to the Code gen. info tab and uncheck the checkbox for the inherited Serializable attribute, or define a rule which resolves to true only for a subset of all entity definitions in the project.

When code is generated for the project, every class representing an entity definition which inherited the attribute will then have the Serializable attribute applied to it. See for more information: How to assign attribute definitions to elements easily and How to assign additional interfaces/namespaces to elements easily.

Conventions: Entity Model, Type Shortcuts

This group allows you to define additional type shortcuts which are used for specifying field types in the editors for entities, value types, typed views and stored procedure calls. Shortcuts make it easier to specify a type. LLBLGen Pro already defines a list of shortcuts for all types supported by all supported databases, which are called the System Type Shortcuts. System type shortcuts are readonly and can't be removed.

Additionally it will auto-create custom type shortcuts for imported types, like enums, and the types supported by loaded type converters, as well as, the CLR UDT types retrieved from a SQL Server database, when working database first.

To add a new custom type shortcut, simply add a new line in the grid on the Custom Type Shortcuts tab and press enter.

For each Custom Type Shortcut, you can also specify the default constraint value for a given database type. This allowes you to quickly specify default values through a custom type shortcut when working Model First.

Conventions: Entity Model, Type Conversions

To overcome .NET type mismatches between the model element and the mapped target element, the LLBLGen Pro designer supports Type converters. Type converters are classes which can convert from one .NET type to another and vice versa. Type Converters are supported on the LLBLGen Pro runtime framework and NHibernate (for NHibernate, the TypeConverter type has to implement the NHibernate specific interface IUserType). There are two kinds of type converters: normal type converters and system type converters.

To set a type converter for a field, you do so on a Field Mappings Tab of the containing element's editor. This can be a time consuming process if your project has a lot of fields which require a type converter. To overcome this, the designer supports Type Conversion Definitions. These type conversion definitions define for a given .NET type pair and optionally a set of filters, a type converter.

If the designer recognizes this .NET type pair and optionally filters match too, and additionally the Project Settings setting Auto assign type converter to field mapping is set to true, the type converter of the defined Type Conversion Definition is assigned to the model field automatically. This happens when you sync the relational model data or when you map an entity onto a target element.

Type Conversion Definitions are stored per database, as different target databases can require different type converters or different filters (as the filters are target database specific). To edit type conversions for a given project, right-click the project node in Project Explorer and select Edit Type Conversion Definitions... or select Project -> Edit Type Conversion Definitions... from the main menu.

The Type Conversion Definition editor edits the type conversions per database. Only databases which currently have a Relational Model Data storage in the project are selectable.

In the Defined type conversion definitions list, the currently defined type conversion definitions are shown with the filters, types and type converters they are based on. To remove a type conversion definition, select it in the grid and click Remove selected. To add a new type conversion definition, click the Add new... button. This will open a dialog which is described more in detail below.

Adding a new Type Conversion Definition

When you click the Add new... button, a dialog is opened which allows you to define the base elements for a type conversion definition. You start by selecting the Relational Model data .NET type. This is the .NET type related to the database type of the table/view field. This type is called the from type. Based on this .NET type, the list of Type converters to select from in the Converter to use combo box is filtered.

After you've selected a type converter in the Converter to use combo box, the Model .NET type is known, as that's the core type of the type converter. Click the OK button to create the Type Conversion Definition, which will be a conversion definition between the Relational Model Data .NET type and the Model .NET type using the Converter to use type converter.

Additional Filters

Per type conversion definition you can specify extra filters. This can be useful when more than one database type results in the same .NET type, or you want to filter on length for example. To enable a filter, check the checkbox in front of a filter element at the bottom in the Additional filters on database field properties area. If a filter is enabled, it has to match exactly with the target field's specific property, e.g. length or precision to get the type converter of the particular type conversion definition assigned to the field mapping.

Conventions: Entity Model, Custom Properties

Custom properties are name-value pairs (name and value are both strings) which can be used in templates to generate project specific information. They can be used to drive custom-made templates, be used as additional output in templates. They don't have a logical function inside the designer. The templates shipped with LLBLGen Pro emit the custom property value pairs in XML DOC fragments into the code, so you can use them to add additional documentation to the various elements.

Besides the Project itself, all major project elements, like entity definitions, value type definitions etc. allow the user to specify additional custom property value pairs. When reverse engineering entities and other elements from the meta-data, LLBLGen Pro will, if available, add the description / additional properties read from the relational model data as custom property value pairs.

The Custom Properties Tab allows you to specify the value pairs for the project itself.

Conventions: Derived Models

Per Derived Model in the project, a set of settings is available, as well as a way to specify additional interfaces, namespaces and attributes. The sections below are defined for each derived model separately. This means that if you have e.g. three derived models in your project, you can configure per derived model each section described below separately.

Conventions: Derived Model, General

PrefixDenormalizedFieldsWithNavigatorName: When set to true (default), a field which is denormalized gets the navigator it is denormalized over as prefix to its name. This is done once. When set to false the field name is left as-is.

Conventions: Derived Model, Target Framework Settings

This group shows the settings related to the target framework chosen, e.g. the settings related to the DTO Class Model framework are located here. See Available Derived Model Target Frameworks for details regarding the settings available per target framework.

Conventions: Derived Model, Code Generation, General

DerivedElementClassNameSuffix: The class name suffix to append to the name of a Root Derived Element or an Embedded Derived Element to form the class name for that element. Default is empty string.

Conventions: Derived Model, Code Generation, Attributes / Additional Interfaces / Additional Namespaces

This section is identical to the section for the entity model described above.

Changing settings and the effect on the model in the project.

The following project settings are re-applied to the project model if they're edited in the project settings dialog. Per setting or setting group a section is added what exactly is propagated to the project model.

Changes to default length/precision/scale of custom type shortcuts are propagated to all fields

The changes to the defaults of custom type shortcuts to all fields using these custom typeshortcuts are propagated to all fields using these custom type shortcuts. This is regardless of whether the user has altered the value of length/precision/scale after the field was created.

Changes to several name construction settings are re-applied to the project

Several of the name construction settings are re-applied to the project model after the project settings have been edited successfully and the value for the setting was changed. The settings which are re-applied are:

All settings under 'Name construction'
All settings under 'Name construction, name patterns', except 'Typed view mapped on resultset pattern'

All names are affected, even if the user changed the name manually.