We are using LLBLGen Pro 4.0 Final. Currently, all our projects use the same (modified) LLBLGen template. There is only one "target" (LLBLGen Pro Framework with SQL Server, VB.NET, .NET 4.0, Adapter), so code generation always uses exactly the same template.

Our version of the template is "installed" by simply replacing certain files inside the installation directory of LLBLGen:

Frameworks/LLBLGen Pro/Templates/SharedTemplates/Net3.5/VB.NET

When the global template is modified, all developers are instructed to re-download the modified template files, and copy them to the installation directory.

This approach was chosen for lack of a better one, and it works. However, we would like to improve things and store the template separately for each project (as part of the source code). Each developer would have exactly the same template version; and if an old branch of a product has to be rebuilt, the LLBLGen Designer would use the old templates, too.

How can this be achieved? I tried to understand the documentation about template bindings, but it is not obvious at all.

I'll try to explain it briefly.

Introduction: LLBLGen Pro uses Tasks and TaskPerforms to generate code, and all that matters, like creating folders, and files. Every Task needs a Task Performer to execute it, and these are shipped with the product.

The mostly used Types of Tasks are Directory Creator, File Creator and Code Generator. All these tasks need some parameters like the destination folder, or when to be executed, example for each entity or for each TypedView, or once per project... etc.

Only the Code Generator Task, needs a Template based on which it should generate the code.

What you need: LLBLGen Pro ships with files which defines the Tasks and templates it needs.

But if you want to create a new Task (say a Task to generate a Text file for each entity in some folder, each file should have some text).

So you need to define the task somewhere (name, which TaskPerfomer it should use, and some default values for its other parameters). You define tasks and group them in task groups if you wish in a *.Tasks file.

This definition of Tasks is still not tied to any project or template.

Now if you need to generate code or text in some files, then you need to define the template in *.template or *.lpt file (the first uses a TDL language, the later uses C# in a more complex way, you can reed all about them in the SDK Documentation File).

Now you templates are just files, that where template bindings files comes to help. You need these to assign an ID to each template file for the target .NET version.

Say you need to generate a class for each entity, but its content will differ if used with .NET 3.x rather than 4.x.

So in the template binding file, you may assign the same template ID twice, once for .NET 3.x to point to some template file, and another time for .NET 4.x to point to another template file.

Final Step

*.preset file. This is the file that defines which tasks you need to use in your LLBLGen Project, and what are the values of their parameters, including the templateIDs used by some for them to generate some code.

In practical, you don't create this file from scratch, but rather you copy from an existing one, and add new sections defining your custom tasks, and which templates they use.

Storing the custom files:

The LLBLGen project has 2 settings called "Additional Tasks folder" "Additional Templates folder". These define the paths (I recommend using relative paths e.g. ".\MyTemplates") of the folders where you store your custom tasks and presets, and/or your templates and templateBindings files.

So you can store these locally in some folders and map these to the source control system. And the LLBLGen Pro file will hold their relative paths.

Hope that clears it a bit.

Thanks for the quick overview.

There are still some open questions:

• Where are the .tasks files referenced in the preset?
• Where are the .templatebindings files referenced in the preset/tasks?

acl wrote:

Thanks for the quick overview.

There are still some open questions:

• Where are the .tasks files referenced in the preset?
• Where are the .templatebindings files referenced in the preset/tasks?

In theory you don't need to use task files, as they're all based on the few bare bones tasks for executing a task performer (code generator engine).

So you could get away with just a preset, by adding a task from the list of tasks to choose from in the code generator configuration dialog (click 'advanced', then go to 3rd tab), and add the 'ConsumeLptTemplate' task. Then fill in the parameters in the preset.

templatebindings files are stored in the additionaltemplates folder specified in the project settings. presets and task files are stored in the additional tasks folder specified in the project settings.

The shipped ones are stored in the <installation folder>\Frameworks<framework>\Tasks and <installation folder>\Frameworks<framework>\Templates

folder. There you can see how it's done. Additionally, please have a look at the additional templates like 'ASP.NET GUI generator templates (Adapter/SelfServicing/ C#)' which are available for download on the website, to see how to create additional templates / presets / tasks without altering existing ones.

If you want to use a template that's an altered version of a shipped one, it's best to create a templatebindings file which binds your copy of the template to the same templateID and give the templatebindings file a higher precedence. This is then shown on tab 2 of the code generator configuration dialog when you press F7 (click 'advanced' first). The higher the templatebindings file the better: it will then overrule all template bindings it redefines in template binding files below it, so the binding in your own templatebindings file will then overrule the one in the shipped templatebindings file which means your copy of the template is used, not the one shipped as your copy is bound to the templateid used.

This is stored in the project after code generation, so if you define the additionaltemplates folder to be relative to the project file, you can simply distribute the project file and the additional files easily and when someone opens the project file, the additional templatebindings are then available immediately.