Frans,

I have taken the leap of upgrading to 2004.2. .

I knew this was not going to be easy as I have a load of custom templates and task performers which I have to be merged with your new versions.

Firstly, is there a recommended way to structure custom template sets within LLBLGen to allow a easier upgrade? At the moment I have to make copies off all the LLBLGen supplied files that I have modified and merge my changes into the files with each upgrade from you which results in a nightmare . Some of these template sets are porject specific and some are global to my LLBLGen install and keeping these under source control and in sync with the files that must reside under ...\Solutions Design\LLBLgen\ is proving cumbersome.

Secondly to the problem.... BUT since starting to write this post I have resolved my issue... I will however leave it here for others to find if they run into the same problem.

There is a breaking change between 2004.1 and 2004.2 in EntityDefinition:

EntityDefinition.TargetTable.TableName is now EntityDefinition.Target.Name

Marcus wrote:

I have taken the leap of upgrading to 2004.2. .

I knew this was not going to be easy as I have a load of custom templates and task performers which I have to be merged with your new versions.

It shouldn't be that hard, there are a couple of things changed internally, but overall it shouldn't be a very huge undertaking.

Firstly, is there a recommended way to structure custom template sets within LLBLGen to allow a easier upgrade? At the moment I have to make copies off all the LLBLGen supplied files that I have modified and merge my changes into the files with each upgrade from you which results in a nightmare .

The templates themselves have been altered here and there to add fields on related fields (entity templates) and hte user code regions. Not a lot of other changes.

the templates you have should be working with 1.0.2004.2, no statements were dropped for example. (the TDL templates). If you want to use 1.0.2004.2 new functionality, I'd suggest you merge your changes with the new templates. You can do that with Winmerge for example. But I don't know which changes you made to the original templates... Perhaps you can add start/end comments where you made changes so you can move the changes to new templates pretty easily.

But I think you've to deal with 2 problems: 1) .lpt templates fail to compile because some objects changed (like EntityDefinition.TargetTable -> EntityDefinition.Target) 2) Modified TDL templates still work, but you don't have the new user code regions and some new features.

Some of these template sets are porject specific and some are global to my LLBLGen install and keeping these under source control and in sync with the files that must reside under ...\Solutions Design\LLBLgen\ is proving cumbersome.

There's now a new folder, 'additionaltemplatesets' inside the llblgen pro folder. In there you can store your own templates, most likely .lpt templates, which are probably driver agnostic.

Secondly to the problem.... BUT since starting to write this post I have resolved my issue... I will however leave it here for others to find if they run into the same problem.

There is a breaking change between 2004.1 and 2004.2 in EntityDefinition: EntityDefinition.TargetTable.TableName is now EntityDefinition.Target.Name

That was a necessary change to make sure a view could be a mapping target. I've tried to keep these changes to a minimum, and they're pretty straight forward so a global replace will do.

Otis wrote:

the templates you have should be working with 1.0.2004.2, no statements were dropped for example. (the TDL templates). If you want to use 1.0.2004.2 new functionality, I'd suggest you merge your changes with the new templates. You can do that with Winmerge for example. But I don't know which changes you made to the original templates... Perhaps you can add start/end comments where you made changes so you can move the changes to new templates pretty easily.

But I think you've to deal with 2 problems: 1) .lpt templates fail to compile because some objects changed (like EntityDefinition.TargetTable -> EntityDefinition.Target) 2) Modified TDL templates still work, but you don't have the new user code regions and some new features.

Everything migrated without too many problems! I had previously marked all the changes like you suggest so they were easily found.

Otis wrote:

There's now a new folder, 'additionaltemplatesets' inside the llblgen pro folder. In there you can store your own templates, most likely .lpt templates, which are probably driver agnostic.

Didn't see that till just now... Can you add subfolders to this if you want to section off by project name for instance?

Otis wrote:

That was a necessary change to make sure a view could be a mapping target. I've tried to keep these changes to a minimum, and they're pretty straight forward so a global replace will do.

No problem, this was the only change that broke anything for me...

Marcus wrote:

Otis wrote:

the templates you have should be working with 1.0.2004.2, no statements were dropped for example. (the TDL templates). If you want to use 1.0.2004.2 new functionality, I'd suggest you merge your changes with the new templates. You can do that with Winmerge for example. But I don't know which changes you made to the original templates... Perhaps you can add start/end comments where you made changes so you can move the changes to new templates pretty easily.

But I think you've to deal with 2 problems: 1) .lpt templates fail to compile because some objects changed (like EntityDefinition.TargetTable -> EntityDefinition.Target) 2) Modified TDL templates still work, but you don't have the new user code regions and some new features.

Everything migrated without too many problems! I had previously marked all the changes like you suggest so they were easily found.

Great!

Otis wrote:

There's now a new folder, 'additionaltemplatesets' inside the llblgen pro folder. In there you can store your own templates, most likely .lpt templates, which are probably driver agnostic.

Didn't see that till just now... Can you add subfolders to this if you want to section off by project name for instance?

You can do whatever you want . It's the startfolder for templatesets, so it will be searched for .config files. So normally, you'd place the template sets which are database agnostic in there (the .config files) and place the templates either in a subfolder there or in another folder.

I created that folder to overcome the weirdness that the manager templates for example, which are database agnostic, had to be placed inside the driver folders, so you had to copy them if you wanted to support multiple databases...