What is best practice when using the tools of Visual Studio, Subversion and Continuous Integration?

1 One LLBLGenPro project for a database (or multiple same type databases) or one project per application or one project per developer? I worry about the first as a db with 150+ tables will produce a big project. I worry about the the latter two approaches as they would allow different object naming to proliferate.

2 Create both Self-Service and Adapter versions as separate projects for use in different styles of application? E.g. Is self-service is most appropriate for web sites, but adapter better for remote windows applications.?

3 Putting the generated code into each VS project or adding the dll from the LLBLGenPro project via svn:externals in subversion (like our other cross application references).

4 What to do with the Continuous Integration system? I have no thoughts on this as I haven't got this far yet, but I would probably want the application to be rebuilt whenever anything is changed in the LLBLGenPro project.

Any tips or suggestions on all or any of the above are very welcome.

Neil

What is best practice when using the tools of Visual Studio, Subversion and Continuous Integration?

Please check the following answers.

1 One LLBLGenPro project for a database (or multiple same type databases) or one project per application or one project per developer? I worry about the first as a db with 150+ tables will produce a big project. I worry about the the latter two approaches as they would allow different object naming to proliferate.

One LLBLGen project per application (Domain/business solution).

2 Create both Self-Service and Adapter versions as separate projects for use in different styles of application? E.g. Is self-service is most appropriate for web sites, but adapter better for remote windows applications.?

The norm is to have one LLBLGen Project per application whether this is an Adapter or a SelfServicing. Also I can't imagine a case where you are going to generate SelfServicing and Adapter code for the same application, other than demoing LLBLGen Pro to other developers. You should use one Model (Template Set) per solution, you can't mix between Adapter and SelfServicing.

You can't have a SelfServicing code for your web application and then an Adapter code generated for the web-service that the application talks to. Entities from the same Template Set should be used in communication between apllication in the same solution.

3 Putting the generated code into each VS project or adding the dll from the LLBLGenPro project via svn:externals in subversion (like our other cross application references).

Whatever, personally I like to integrate the generated code into my solution in case I needed to trace some issue down to the generated code.

4 What to do with the Continuous Integration system? I have no thoughts on this as I haven't got this far yet, but I would probably want the application to be rebuilt whenever anything is changed in the LLBLGenPro project.

How would you like to initiate the automatic build? If you integrate the generated code in the solution and thus in the source control system, then any change in the generated code files can be easily propagated through out the system and thus any developer who will take latest version from the source control (which should e a daily routine) should ave a latest build of the solutiion.

[neil] Thanks Walaa. A couple of questions below

Walaa wrote:

What is best practice when using the tools of Visual Studio, Subversion and Continuous Integration?

Please check the following answers.

1 One LLBLGenPro project for a database (or multiple same type databases) or one project per application or one project per developer? I worry about the first as a db with 150+ tables will produce a big project. I worry about the the latter two approaches as they would allow different object naming to proliferate.

One LLBLGen project per application (Domain/business solution).

2 Create both Self-Service and Adapter versions as separate projects for use in different styles of application? E.g. Is self-service is most appropriate for web sites, but adapter better for remote windows applications.?

The norm is to have one LLBLGen Project per application whether this is an Adapter or a SelfServicing. Also I can't imagine a case where you are going to generate SelfServicing and Adapter code for the same application, other than demoing LLBLGen Pro to other developers. You should use one Model (Template Set) per solution, you can't mix between Adapter and SelfServicing.

You can't have a SelfServicing code for your web application and then an Adapter code generated for the web-service that the application talks to. Entities from the same Template Set should be used in communication between apllication in the same solution.

3 Putting the generated code into each VS project or adding the dll from the LLBLGenPro project via svn:externals in subversion (like our other cross application references).

Whatever, personally I like to integrate the generated code into my solution in case I needed to trace some issue down to the generated code.

4 What to do with the Continuous Integration system? I have no thoughts on this as I haven't got this far yet, but I would probably want the application to be rebuilt whenever anything is changed in the LLBLGenPro project.

How would you like to initiate the automatic build? If you integrate the generated code in the solution and thus in the source control system, then any change in the generated code files can be easily propagated through out the system and thus any developer who will take latest version from the source control (which should e a daily routine) should ave a latest build of the solutiion.

[neil] How does putting the generated source into a solution work with multiple solutions and developers then? Does that mean that each developer could change all the object names just for thier solution? Or can we create a master project with all the object names agreed by the team so developers choose the entities needed for a particular solution without modifying them?

[neil] I would like any change to the database tables/views to rebuild the LLBLGenPro projects followed by the solutions that depend on them before the database schema changes are checked and deployed. Hopefully, automated tests would then highlight all or most problems. Can we do this, or is it wishful thinking:-) At the moment, the solutions that depend on our current mapper get rebuilt by CI only when the new mapper dll is committed to the svn:externals location.

neilx wrote:

2 Create both Self-Service and Adapter versions as separate projects for use in different styles of application? E.g. Is self-service is most appropriate for web sites, but adapter better for remote windows applications.?

this is a good explanation of that

neilx wrote:

How does putting the generated source into a solution work with multiple solutions and developers then? Does that mean that each developer could change all the object names just for thier solution? Or can we create a master project with all the object names agreed by the team so developers choose the entities needed for a particular solution without modifying them?

That depends upon your needs. If the project is largely used in other applications and developers extend the framework and add other things, the best way could be share the LLBLGen generated code. At the other hand, if people customize the generated code individually or just use a subset of entities, they could create and generate their own llblgen projects.