Hi,

We've been using LLBGen for quite some time now and it is quite integrated into our VS solution's sites and web services, but we managed to do something really stupid (Not checking into Soursesafe followed by a really dumb undo checkout WITHOUT leaving a local copy) which has resulted in us losing the most recent LGP file / project used as basis for generating the LLBGen code / classes.

I'm almost certain the answer is likely to be no, however just thought we'd ask before we assume its a no, whether it is it at all possible to recreate / regenerate / reverse engineer (there might be a more appropriate word though) the LGP file from the generated code & classes, i.e. do the reverse of what one usually does (generating the code from the LGP file / project).

It could save us a lot of time with us having made quite a fair amount of changes to our database structure (and resultantly to the generated code) from between the last LGP file we had committed to SourceSafe and the one we lost by the dumb SourceSafe mistake.

If not, we are just going to have to use WinDiff comparing our latest live generated code with that generated from the last LGP file in order to establish what we need to reapply to the LGP project file in order to generate the same code as we have live.

Hope this made sense.

Thanks, Keith

Hi Keith,

That's is really an unfortunate situation Let's see what are your options...

A. Since you say "LGP" I assume you are using a v2.x version, because the v3.x versions now use a plain xml format file (.llblgenproj), which means that is possible to compare project files in v3.x. However, since you are using v2.x, you can't.

B. Create the LGP project from scratch. This probably sounds awful but you should consider it. You just need to reverse-engineer the DB and start making changes to your entities to mimic the changes you made before. Then generate code to an empty folder and start comparing files (your working version vs. this new one), then make changes again, and so on. I would go for this option, I guess.

C. Going from code to LGP. Although this is theoretically possible, it seems like a lot of work: you should create a VSNet project and start learning/using the LLBLGen Apis (ApplicationCore, DBCore, etc.), then you have to, somehow, use refactoring or parser strategies to read your classes and based on that, create a LLBLGen project with the LLBLGen apis. I don't know of anyone who actually has done this. Also I have the feeling that this breaks some license clauses.

In short, I recommend you "B", as it's more natural. At the end of the day I think that would be more straight-forward. Even if the generated code results a little bit different you could refactor your solution to make it work. Anyway, good luck in this journey

Option B is perhaps indeed the way to go. Make sure you set the naming patterns etc. (in the project properties!) to the values you want to use before creating any entities, so you don't have to do a lot of renaming.

You could also try to start with the latest copy you have and simply do a refresh of the catalogs. If you have set the project properties correctly, you will get new entities for newly found tables, and they're properly named using the naming patterns you have set.

Hi daelmo & Otis.

Thank you both very much for your detailed and prompt responses.

Correct - We are indeed not yet using LLBGen3, but good to know of the XML format (will make comparisons a lot easier to do).

We have started the process of using option B to determine our most recent changes and we are closing in on getting our LGP project file to where it generates the same code as in use in our live system.

Big lesson learnt here: Make sure to make backups of LGP project file!! (In our environment = Make sure to check changes into SourceSafe once having generated new code from it)

Much appreciated again!

Keith