MattWoberts thread from earlier today is timely to my current needs, but I need a little help with the implementation details:

Background: I've spent the past couple of months (part-time) working on a web app using LLBL Gen Pro. I've done it all locally on my laptop. Now, my friend is ready help out with the coding so we have moved everything into VSS. All the version control functionality works as expected but we are a little concerned about our current approach regarding the assemblies and VSS. (Note: Both of us have significant (10+) years development experience with several version control systems -- just no relevant experience to managing the .Net assemblies within source control)

Project Structure: Our current structure is: \DAL -- DALGeneric (references SD/LLBL ORMSupportClasses assemblies) -- DALSpecific (references SD/LLBL ORMSupportClasses + DQE.SqlServer assemblies) \BLL -- BLL Project (references SD/LLBL ORMSupportClasses + DALGeneric + DALSpecific assemblies) \Web -- \Core ---- Core Project (standalone assembly - contains some common web functionality) -- \App ---- App Project (references SD/LLBL ORMSupportClasses + BLL + DALGeneric + DALSpecific)

Right now, while developing, I have a solution with the App, BLL, DALGeneric and DALSpecific projects in it. In theory, I probably don't need the DAL projects in this solution, but early on it made it easy to see what was going and what objects I was dealing. The DAL assemblies so far would only change when the database has changed since I have left all of the generated objects alone.

So, my questions: 1. Is having all of those projects in one solution the way to go? Or should I trim back and only have the BLL and App projects in there? 2. In each project, when referencing dependencies, should I reference the projects or the assembly? We've tried to reference the projects, but were having issues and had to go back to referencing the assemblies. 3. If I have all of these projects in the solution, does it generate a new assembly for each project, or only if things have changed? 4. Do you keep the default \debug and \release paths for creating assemblies, or do you just build to the \bin folder? 5. For the SD assemblies, should we have a folder in VSS for Third Party Assemblies or Referenced Assemblies and then share the DLLs out into the appropriate project release folders? 6. Do you store the generated project assemblies in VSS? Or rely on a build process to create the assemblies? We keep running into permission errors because the assemblies are currently in VSS and when you Get Latest, they come down as read-only and when you try to build the project, it has errors that it can't overwrite the assembly. So, do you set it to writable for the time being and if you've made any changes go ahead and check it out?

Sorry for the long process. I'm sure we could work through a lot of this by trial and error, but wanted to try not to re-invent the wheel. We do plan to have an automated build process at some point in time, but it is farther down the list. Any feedback or personal experiences or links to write-ups on the topic is greatly appreciated.

Thanks, Matt

Hi there,

I asked frans in an email about adding the generated projects to the solution, his reply, which i agree with and am in the process of doing:

I'd go for a separate solution with the generated code. The thing is that a vs.net solution should contain the code you're working on, everything else shouldn't be in code-form as it will slow down the IDE and the compilation process. 

1. In each project, when referencing dependencies, should I reference the projects or the assembly? We've tried to reference the projects, but were having issues and had to go back to referencing the assemblies.

Always try to reference the projects - project references are much more dependable and relieable - and offer benefits. For example if you run teh web app in design more, all the design dlls are referenced. If you run the app in release mode, all the release dlls are referenced.

1. If I have all of these projects in the solution, does it generate a new assembly for each project, or only if things have changed?

An assembly for each project is creeated when you "rebuild". When you build. it should only build the changed projects, so for example you wont find the generated code being rebuolt time and time again when you hit "build solution"

1. Do you keep the default \debug and \release paths for creating assemblies, or do you just build to the \bin folder?

We did change ours, but got bitten by so many problems I had to change them back to defaults

1. For the SD assemblies, should we have a folder in VSS for Third Party Assemblies or Referenced Assemblies and then share the DLLs out into the appropriate project release folders?

Thats what we do - some developers dont have llblgen installed and this stops it being a problem. I would also consider creating a "project" within the solution that contains the dlls only, so that when you "get latest soluton" from vs.net, they are also returned.

1. Do you store the generated project assemblies in VSS? Or rely on a build process to create the assemblies? We keep running into permission errors because the assemblies are currently in VSS and when you Get Latest, they come down as read-only and when you try to build the project, it has errors that it can't overwrite the assembly. So, do you set it to writable for the time being and if you've made any changes go ahead and check it out?

Store the generated assemblies in VSS only if you aren't including the projects as part of the solution. You said that you currently have the generated projects as part of the solution, in which case theres no need to add these dlls to sourcesafe - its just extra hassle. Go with the "build script approach". Also - take a look at finabuilder, it rocks.

Hope that helps. I've been round with the same quiestions myself!

MattWoberts wrote:

Hope that helps.

It does. I'll be working with some of your suggestions over the next few days.

Thanks!