LLBLGen Pro v3 has a new project file format: it's in XML, easy to read and is stored in files with a different extension: .llblgenproj. To convert an LLBLGen Pro v2.x project, stored in a file with the extension .lgp, you have to use a conversion template using the v2.x designer. The v2.x designer can load the .lgp project and with the template it can generate a v3 llblgenproj project file. The conversion procedure is described below. It's highly recommended to use the latest v2.6 designer build from the Customer area to convert the project, even though you're using v2.5 or earlier. The latest v2.6 designer build is free for all v2.x licensees.
Before you start the LLBLGen Pro v2.x designer, please unpack the v2xMigrationTemplates_date.zip file found in the folder V2xMigration in the LLBLGen Pro installation folder (or download the latest build of this migration template package from the customer area) into the v2.x designer installation folder. It will install a new templategroups.config file in the AdditionalTemplates folder. If you get a prompt to overwrite this file, you already have such a file in that folder, you should click 'No' to not overwrite that file. Instead, open the templategroups.config file in the AdditionalTemplates folder and add:
<templateGroup name="LLBLGen Pro v3" description="Template group which contains templates for converting v2 projects to v3 project files."/>
Start the LLBLGen Pro v2.x designer and load the project to convert. Press F7 to bring up the code generation dialog. For 'Template group' you select 'LLBLGen Pro v3'. Choose a .NET version and language, that's not important. Specify the destination root folder you want the .llblgenproj file to be created in.
Click Start generator. The project is now generated as a .llblgenproj
file. In the destination folder you have chosen, a file called
ConvertedProjectv3Format.llblgenproj has been created. This is your v3
version of the .lgp project. Rename the file to your liking, e.g.
after the project name.
Note for type converter users: if you use type converters in your LLBLGen Pro project be sure you copy them to the 'TypeConverters' folder of v3.0 before you initially load the project. If you use enum types in your type converters, be sure to define a .typeimports file before loading the llblgenproj file for the first time.
Start the v3.0 designer and load your converted project file. If you get an error, like a type couldn't be loaded, make sure that if the type is typeconverter related, you have placed your type converter in the v3.0 TypeConverters folder or a folder which is reachable by the v3.0 designer.
After you've loaded the project, it might be v3.0's designer finds errors. This is likely caused by more strict rules implemented in v3.0's designer. Manually fix the errors reported, if the designer reports any. After that, refresh your catalogs. The project should now validate and is ready to use. After you've successfully converted the project, first check the new preferences and project properties and adjust them to your liking before proceeding.
The template emits XML, using the .lpt mechanism, however it doesn't sort the elements in the right order. It's not really a problem as loading the generated llblgenproj file and saving it again will save it in the right order. You have to take this into account however when you check-in the initial generated file into source-control and after that you try to update that file with a saved version: it will show a lot of changes which likely aren't changes. This is a one-time thing.
Relationships are always specified as FK-PK. This is a convention to get rid of the duplicate relationships which are present in v2's projects (in v2.x, a m:1 relationship is also present as 1:n in the PK side), now the FK-PK relationship is stored both in the pk and the fk side.
In v3 we don't have custom relationships anymore: all relationships seen in v2's project are considered usable, unless the relationship is marked as hidden. It can be the user has created multiple custom relations in v2, where the FK side has a custom relation to both A and B and both A and B are mapped onto the same table. These relations aren't filtered out but could lead to crashes or non compilable code. This edge case has to be corrected manually in the designer.
All normal relationships which have their start entity as the FK side are emitted into the output, unless they're marked hidden, or used for hierarchies. If the relationship doesn't have an opposite, the relation is emitted, if the FK side is the start entity, otherwise the relation is ignored, as it's not a concept that's known in v3. Instead, in v2.x, the user should unhide the relation and hide the field mapped onto the relation. Custom relations which are present in just one side are seen as normal relations