Guys,

We will be migrating a project which uses LLBLGen 1.1 to 2.0 and am currently trying to re generate the code using the project settings. However I'm confused as to the key differences between the template bindings for the self servicing 2 class style.

It seems we can use

a) SharedTemplates.BackwardsCompatibility b) SqlServerSpecific.NET20 c) SharedTemplates.NET20

The help doesn't mention much about this except to say b and c generate "more compact" code.

What are the key advantages of b and c over a or even b over c. Will we get performance issues over each one, if we get compilation issues by going for one approach, should they be easy to rectify?

We use SQL Server as the data store and will consider migrating to SQL Server 2005. We don't have any need to support other database platforms however obviously this would be advantegous if we went down a route which easily supported this.

Let me know your thoughts?

You don't select one out of those 3 template bindings.

All of them are used in the generation of your code, you only get to specify their precedence (Their order defines according to which template binding the code will be generated in case of smiliar templates in more than one template binding.)

From the docs:

LLBLGen Pro ships with a standard set of templates and accompanying template bindings files. For some templates there are multiple versions, like the ResultsetFields templates: one version which generates code as it was done in LLBLGen Pro v1.0.2005.1 and one which is slightly modified and generates different code which is more compact, and which is new for V2.0 of LLBLGen Pro. The former template, the one which generates code like v1.0.2005.1, is bound to the particular templateIDs in the templatebindings file called "SD.TemplateBindings.SharedTemplates.BackwardsCompatibility.NETxx", where xx is the target platform version number. The latter is defined in the standard templatebindings file called "SD.TemplateBindings.SharedTemplates.NETxx".

Both bind different files to the same TemplateIDs.To place one templatebindings file above the other one, it overrules the templatebindings to the same TemplateIDs. In the screenshot above, the backwards compatibility templatebindings file is placed above the standard shared templates templatebindings, which means that for the TemplateIDs which are in both templatebindings files (in this case SD_ResultsetFieldsAdapterTemplate and SD_ResultsetFieldsTemplate), the files bound in the backwards compatibility templatebindings file are used, because those templateIDs take precedence over the ones in templatebindings files placed below it.

You can change the precedence of a templatebindings file by selecting it and then by clicking the move up/down buttons at the right of the list. The order in which the templatebindings are placed at the time the code generation is started is preserved in the project file.

You can use this mechanism also to overrule a template binding in the standard bindings to use your own version of a shipped template. See for more information about how to create your own templatebindings files the LLBLGen Pro SDK documentation.

Thanks can you answer my point about each template then

What are the key advantages of b and c over a or even b over c. Will we get performance issues over each one, if we get compilation issues by going for one approach, should they be easy to rectify?

What are the effects of placing the precendence of b and c over a or b over c?

If you click on a you'll see the template bindings defined in that templatebindings. b and c contain different templates. a contains resultsetfields templates as described in the manual: Using the generated code -> adapter/selfservicing -> using typed views typedlists and dyn. lists -> using dynamic lists:

LLBLGen Pro v2.0's different ResultsetFields classes In LLBLGen Pro v1.0.2005.1 and earlier, the generated ResultsetFields class in the HelperClasses namespace contained a lot of overloads of the DefineField() method. By default, LLBLGen Pro still generates this code, however also offers a new way to define fields in a ResultsetFields object which is more efficient, namely instead of using the FieldIndex enums, it uses the generated entitynameFields classes. If you're creating a new project with LLBLGen Pro you can avoid having all the DefineField overloads in the ResultsetFields class, by moving the BackwardsCompatibility templatebindings to the bottom of the list in the Generator configuration dialog. Please see: Designer - Generating code. By default the BackwardsCompatibility template bindings take precedence over the more compact newer templates to let people who upgrade existing code to LLBLGen Pro v2.0.

I.o.w. if you're using dynamic lists with: fields.DefineField(CustomerFieldIndex.CompanyName, ....)

you need to overrule the new template with the backwards compatibility one so you then place a over c. If you don't use these, place a below c so the bindings of c take precedence over the bindings in a. You'll then don't get all the overloads in ResultsetFields but a small class which accepts entity field objects instead.