The Author Online Book Forums are Moving

The Author Online Book Forums will soon redirect to Manning's liveBook and liveVideo. All book forum content will migrate to liveBook's discussion forum and all video forum content will migrate to liveVideo. Log in to liveBook or liveVideo with your Manning credentials to join the discussion!

Thank you for your engagement in the AoF over the years! We look forward to offering you a more enhanced forum experience.

neslekkim (2) [Avatar] Offline
Maybe I bought the wrong book, but I was looking for something that was a bit closer to the various CI tools like CCNET.

I'm looking for ideas and thoughts around how to organize projects where you have solutions that use common projects etc.

like, You have an solution A which have projects p1 and p2.
These are used by solution B with project p3 which uses p2, which in turn references p1.

and then you have project C which uses p3.

The goal, is that the various outputs, should not be compiled multiple times, and the other solutions that uses the various outputs needs to be triggered when the others are recompiles, which was the point with CI.

For some reasons, some developers would like to have solution B with projects p1, p2 and p3, so they can bugfix p1 based on what happens in p3. this means that the project-file for this developer will have project-reference to p1+p2, and not binary reference to those. And of course that developer will have to maintain his own solutionfile.

So.. for some reason, I don't want to have MSBuild to build solutionfiles, but instead build the projectfiles, and use projects etc inside CCNET's configfiles to group together the various projects to the so called "solutions".

Any ideas?
marcin.kawalerowicz (11) [Avatar] Offline
Re: Best practices?, project and solution organization?

I think you bought the right book. Although the CI is not all about organizing the projects we are discussing the issues you have. Please have a look at chapter 2 for the SVN externals example. In chapter 4 you have a part about triggering builds - it's all about organizing the various projects in the CI process.

Best regards,
Marcin Kawalerowicz
neslekkim (2) [Avatar] Offline
Re: Best practices?, project and solution organization?
yes, svn:externals is an solution, have used it a little bit, but it gives us major headaches because when branching/tag'ing etc, the reference will always be the same, so it will reference the treenode, not the actual version at the time you branched/tag'ed etc.
to do that, you ned to change the svn:externals to point to an specific version in time to make sure you reference the correct version.

But this would not actually help since you are then making project references, which we do today in the solution&project files, to include projects residing other places (using relative paths, since all is in the same repo)

But what i want in the CI process is to reference already compiled dll's, to make sure that one project using one dll, and another project using the same dll actually uses the SAME dll, not compiled again from the same source.. (this is because some customers use one projects, other uses the other projects. And some again uses both, and we want to make sure they don't have the "same" dll's with different timestamps and so on.. which again is an msi-install-builder issue, but still, we want to pull everything from the ci server)