Hi, i can confirm ruben's explanation. It was till this day the best solution for a large real world project with over 150 assemblies/projects.
But you can also create a new CCNet project that gets the latest binary of Lib A and tests compilation + unit tests agains the main project. Example: - Project for Lib A - Project for MainApp - Project for integrationtest of latest Lib A + MainApp Daniel Am 16.07.2010 12:33, schrieb Ruben Willems: > Hi > > that remains to be seen :-) > > suppose : The guys on the lib project are working very hard : 50 > commits a day > > Do you really want to see 50 broken builds for every main project ? > those 'broken' builds are not the fault of a 'main' project ! > > A programmer of a main project has it's own tasks, and as long as the > current version of his lib is ok, > why should he upgrade to every in-between version of lib (which has > not been tested, ...) > > > and how much time is it so update the reference? > copy over the new files > check in > > 5 minutes work at most > > > > with kind regards > Ruben Willems > > On Fri, Jul 16, 2010 at 12:17 PM, Benjamin Baumann > <[email protected] <mailto:[email protected]>> wrote: > > This effectively sounds more reasonable and cleaner. > I will see if the amount of time lost whenever you update the lib > with this method (update by hand each project depending on lib) is > worth the change. > > What annoys me is that I not only don't automate the process, but > i add more handmade work (test each project instead of letting > CC.NET <http://CC.NET> do the tests). > > > 2010/7/16 Ruben Willems <[email protected] > <mailto:[email protected]>> > > Hi > > > but you use the dlls from lib, are these dll's not in a > separate folder structure in your main project? > > root > refs > lib > src > main > > > so whenever lib changes, a 'main' project will not break, > because it uses it's own 'copy / version' of lib > > when you want to change to a new version of lib, replace the > one in the refs folder, and you can see if it works or not > before you check in. > > That sounds like a more reasonable approach > > > with kind regards > Ruben Willems > > > On Fri, Jul 16, 2010 at 10:28 AM, Benjamin Baumann > <[email protected] <mailto:[email protected]>> wrote: > > Hi, > > I want to do what you tell, I can do it with forcebuild > publisher or with a project trigger. This is not problematic. > > But I also want to check if lib must be built when I want > to build main. > For example, if there is a commit for both projects main & > lib : I want lib to be built before. As far as I > understand the doc, queues can order project builds but > only pending projects. > > If there is no project building when the commit is done. > Main will maybe trigger before lib and then my queue will > be like this : > > 1. main (svn trigger) > 2. lib (svn trigger) > 3. main (forcebuild or project trigger) > > The first problem is that main is built two times, the > second is that the first build of main may be broken > because it would use the old lib. > > > With kind regards, > Benjamin Baumann > > 2010/7/16 Ruben Willems <[email protected] > <mailto:[email protected]>> > > Hi > > > so you use the dll's from the lib assembly in your > 'main' project. > --> this is ok > > and when the lib is changed, you want to recompile all > apps that use this lib correct? > > > > with kind regards > Ruben Willems > > On Fri, Jul 16, 2010 at 10:11 AM, Benjamin Baumann > <[email protected] > <mailto:[email protected]>> wrote: > > Hello, > > Unfortunately my lib project (in fact I have many > projects matching this case) is used by several > main project. > If I have a solution for each main project, I need > each time to specify the path to the libs projects > and these paths may change according to the > computer where the development takes place. > > That's why I prefer to reference dll built in the > integration server, and that's why I have to > re-build (if needed) these dlls prior to build the > main project. > > With kind regards, > Benjamin Baumann > > 2010/7/15 Ruben Willems <[email protected] > <mailto:[email protected]>> > > Hi > > why not have 1 solution that has lib and main? > > so the solution takes care of the dependencies. > > > with kind regards > Ruben Willems > > > On Thu, Jul 15, 2010 at 5:12 PM, Benjamin > Baumann <[email protected] > <mailto:[email protected]>> wrote: > > Hi all, > > I read the doc and lots of articles and I > ended up with the idea that there is no > easy way to build dependancies before the > triggered project itself. I just would > like to know if I am right or if I forget > something? > > ForceBuild is quite a solution but it > cannot prevent duplicate builds if by > example I commit changes for both project > lib and main (where main depends on the > output of lib), the build of the main > project may be triggered before the build > of the lib project and i would end with a > queue like > 1. main (svn trigger) > 2. lib (svn trigger) > 3. main (forcebuild) > > I actually want the build queue to be : > 1. lib > 2. main (forcebuild) > > But to achieve this, i need a way to force > lib to be built before main... > > Thanks you in advance, > Benjamin Baumann > > > > > > > >
