page header

Project Settings

Each project has its own set of settings, most of them initialized with a value inherited from the Designer Preferences. These settings are called Project Settings, and are editable through the Project Settings Editor. The meaning of each property setting is described below. Each property 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.

A project setting overrides a preference with the same meaning. This helps with a consistent designer behavior when a project file is shared among team members: the project properties are stored inside the project file, the designer preferences are stored locally on the user's computer.

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. This brings up the following dialog:

Project Properties Editor

The Project Settings Editor

General

Designer behavior
Miscellaneous
Validation / Relational model data adjustment

Conventions: Element Name Construction, General

Name construction
Name construction, Name patterns
Name construction, Strip patterns

Conventions: Element Name Construction, 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:

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 so example: addrTABAddressCRLF

Conventions: Database First Development, General

Reverse Engineering

Conventions: Database First Development, Catalog Refresher

Catalog Refresher

Conventions: Model First Development

Designer behavior
Relational model data element construction

Conventions: 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: Code Generation, General

Task performers, General

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

This allows you for example 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: 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.

Conventions: 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 refresh 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.

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


LLBLGen Pro Designer v4.1 documentation. ©2002-2013 Solutions Design