Matching Code to LlblGenPro Project

Posts   
 
    
arschr
User
Posts: 894
Joined: 14-Dec-2003
# Posted on: 30-May-2006 16:24:05   

I have a bunch of Llbl Projects in a folder, The current and a bunch of backups, created as things changed in the generator.

I also have a set of folders with the source code generated by llblgen.

Is there a way by inspection of the code and project or a property at runtime to determine which of the project files was used to generate the code?

This is with v2005.1

Walaa avatar
Walaa
Support Team
Posts: 14995
Joined: 21-Aug-2005
# Posted on: 31-May-2006 08:10:45   

I guess you may match them by the order of file modified date. The older the lgp project match the older generated project, and so on.

Not pretty much of a smart or automated way, sorry disappointed

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39928
Joined: 17-Aug-2003
# Posted on: 31-May-2006 11:11:15   

I think the file modification date is a good candidate. If you have more time, you can write a little utility which picks up the compiled assembly of the generated code and the .lgp file (check one of the command line tools' sourcecode how to easily load a project file), and for example traverse the entity objects in the Project.Entities collection and see if there are accompanying classes in the generated code assembly. If not, the generated code isn't created with that .lgp file.

Frans Bouma | Lead developer LLBLGen Pro
arschr
User
Posts: 894
Joined: 14-Dec-2003
# Posted on: 31-May-2006 13:52:37   

Thanks.

I've since included the llbl project file into source control, so I can better answer this question, but, I think the llblgen in beta maintains a version on the objects in the project? I don't know if the version is maintained per object in the project or of the project as a whole.

If the project maintained a version (that was visible via ui), and it was generated into the source comment headers. This might be more easily resolved.

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39928
Joined: 17-Aug-2003
# Posted on: 31-May-2006 13:58:55   

arschr wrote:

Thanks.

I've since included the llbl project file into source control, so I can better answer this question, but, I think the llblgen in beta maintains a version on the objects in the project? I don't know if the version is maintained per object in the project or of the project as a whole.

Per object. So it's capable of tracking changes on a field for example. Not a changelog, but that it has changed and when.

If the project maintained a version (that was visible via ui), and it was generated into the source comment headers. This might be more easily resolved.

You know you just answered the question I had 'what to do with the TDL statement currently in the templates which used to emit the template version used', as it doesn't do anything. I can change that to a project version used which IMHO isn't there. Good idea, I'll add that to the templates.

You can inspect the version of an object using the project inspector plugin in v2. Right click project node in project explorer -> plugins -> project inspector.

Frans Bouma | Lead developer LLBLGen Pro
Otis avatar
Otis
LLBLGen Pro Team
Posts: 39928
Joined: 17-Aug-2003
# Posted on: 31-May-2006 17:47:24   

Hmm. It's not a good idea to generate teh version into every header, as that will probably make VSS users upset as every little change in the project will make every generated file look changed...

Frans Bouma | Lead developer LLBLGen Pro
arschr
User
Posts: 894
Joined: 14-Dec-2003
# Posted on: 31-May-2006 18:02:03   

Hmm. It's not a good idea to generate teh version into every header, as that will probably make VSS users upset as every little change in the project will make every generated file look changed...

True, perhaps the project version goes just into one header (for some project wide object).

Since (in most cases) the whole source tree for the two llblgen projects is going to be replaced, each header might get the version numbers of the objects that were used to gen the specific stuff represented in the file. That way if the objects used versions didn't change the generated source wouldn't either.