Implementing support for a 3rd party O/R mapper

LLBLGen Pro supports more than one target framework. To implement support for a target framework the following steps have to be taken.

Info

If the O/R mapper requires different ADO.NET providers than which are supported by the designer, you also have to implement a driver. Please see the LLBLGen Pro sourcecode archive for the sourcecode of existing drivers, to get started.

Support for a target framework, the O/R mapper, consists of the following parts:

  • A .framework file. This file describes the target framework core specifics as to be known by the designer.
  • A .frameworksettings file. This file defines the setting definitions specific for the target framework. These settings can be used in templates to customize the generated code
  • A framework validator assembly. This assembly should contain a class which derives from SD.LLBLGen.Pro.ApplicationCore.Extensibility.FrameworkValidatorBase, and the location of the assembly should be provided by the .framework file. The validator is instantiated during the project validation phase to allow target framework specific validation. Implement validation in this validator to raise errors / warnings for used designer features which aren't supported by the target framework
  • One or more .templatebindings files which bind templates to template IDs
  • One or more .preset files which define the tasks to execute for the code generation process
  • One or more .template / .lpt template files which are bound by the .templatebindings file(s) and which are used for generating code.

It's recommended you use .lpt template files for your framework. All 3rd party target frameworks for LLBLGen Pro are developed using .lpt templates. You could use one or more of these templates as a base for getting started.

It's not necessary to have a validator for your framework, though it's in general recommended, as features of the designer used in a project result in expectations with the user about the generated code. If elements are ignored because they're not supported by the target framework without notifying the user is not a situation which is really user friendly.