Can someone please point me to some best practices for using LLBLGen? I would like to know the best way to design my solution and how best to manage source control (Vault (ROCKS!)) and still be able to regenerate. Also, what is the best way to manage this in a multi-developer environment.

What we use here: - sourcecontrol (subversion, but Vault is similar) contains the .lgp file. - It is not always wise to add generated code to sourcecontrol systems, as you can re-generate this code using the checked in project. The reason for this is that re-generating code can cause a lot of changes which can make your database to grow a lot. - adding generated code to sourcecontrol can be wise if you alter f.e. the generated code, add classes to the project, or want to have the generated code in sourcecontrol to keep the code as generated on a given point in time (because templates change of course) - we use edit and commit style of sourcecontrol (subversion's only way of dealing with it) which is also supported by Vault. This means that you can generate code on top of the generated code without having to worry if files are read-only (if you have them added to sourcecontrol)

Working in teams: often 1 or 2 persons are responsible for the generated code. Others use teh generated code supplied by these people.

I personally only keep the lgp file in source control, since I'm the only person responsible for maintaining the data access code. I rarely don't make any changes after the code is generated (other than to tweak a few project files for whatever reason), so I can always regenerate and recompile at any time without worry. It works pretty well for me and the few people that work with me.

We have a team of 4 (and growing) so source control is very important to us. Only two of us change the data access layer (DAL).

We use subversion and the latest beta of the PushOK subversion proxy (www.pushok.com) which seems quite stable now and has the advantage of using the integrated visual studio source control features (unlike Ankh).

We store our lgp file in source control and also store our generated code in source control. While you could decide not to store the generated DAL code in source control and so regenerate it as needed, everyone needs the DAL code and we don't want everyone having to regenerate individually. Of course you could also generate the DAL dll once and then distribute that to all of your team - but then you'd be putting the .dll into source control - which is ok. But for us, it worked better to just checkin the DAL generated code into source control and then everyone gets a copy in the solution. This means too that we have a clear snapshot of the generated code at any point in time.

We structure the DAL as follows: - we have one project that contains the .lgp file - we have one project with the db generic generated code - we have one project with the db specific generated code

How we modify the DAL is: - check out the lgp - check out the db generic generated code project (this checks out all source files within this project) - check out the db specific generated code project (this checks out all source files within this project) - double click on the lgp file to open it in the llblgen pro gui - make the necessary changes - generate the code - this will overwrite the existing source files - save the lgp project - compile your code - ensures that everything generated fine and your code works with the newly generated code - check in the lgp and the two generated code projects

This process didn't work this easily prior to Frans implementing project updating. We used to have to remove the projects from the solution and add the newly generated ones back again which was a pain. Now that the project files are updated, everything works smoothly.

The only drawback with this is that if you change the DAL code, when another developer does a source update, the update can be slow since there are a lot of files updated (it will be every source file in the DAL since every file is changed - if only to update the "generated on" comment at the top of the source file). But we don't currently find this a big issue at all as it only happens when the DAL is updated and that is infrequent. I would assert that once you get your database stable, it won't change much. If you have a very large DAL, the update time could potentially be a problem but you'd have to make a judgement call (and you can always separate your DAL out into another solution).