This is starting to get a little OT, but here's how we have it set up. The programming dept. of our company is pretty small (4 programmers and 3 designers) and we do mostly consultancy stuff (mostly websites), so that means a ton of separate projects, and a few libraries we use across all projects. Since we're lazy we want to put as much code in our libraries, so we can use new features on everyone's project without copy/pasting.
We used to use relative paths to include the codebase .csproj's in whatever client solution, but that relied on everyone having their local source trees set up identically. Since there's only a handful of us, that was manageable, but I could see that getting hairy with larger groups. What we have now is more flexible, but space inefficient. We use subversion's "svn:externals" feature to make each solution think it has a copy of all the codebase projects in it's source. Specifying the externals acts kinda creates a symbolic link. More info: http://svnbook.red-bean.com/en/1.1/ch07s03.html This has several advantages for us: 1. The solution is self contained, so we have repeatable builds 2. Every solution has the latest versions of our codebase (may not be what you want) 3. Adding functionality to the codebase is easy If you have stable libraries, then the /Libraries/xxx.dll method is pretty good, I think. That's what we do for including log4net and nunit. If your libraries are under development pretty regularly, I find having the source available really handy, as I can add a function as I need it, or debug into the codebase if I'm having problems. If you need different solutions looking at different revisions of your libraries, you could set up the svn:externals (or whatever the equivalent is in your SCM) to point to that branch. Oh, right, NAnt. Ummmm... ahh yes, then I use the NAnt <solution> task to build the sln, which handles all the dependencies. Thanks, Ryan -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Thomas Tomiczek Sent: Friday, May 06, 2005 9:21 AM To: Selke, Anthony; nant-users@lists.sourceforge.net Subject: RE: [Nant-users] any suggested strategies for an environment where new project dependencies are constantly being added? Considered yes, but this is not really a good way to do it since one of the things we want to get are REPEATABLE builds. Plus, thse frameworks are, ocasionally, destabilizing when we rework them for a missing feature. So, what we do now is have a "Library" folderin the product. We add all dll's to this folder (and share it into every solution again, so that Source Control in Visual Studio sees the imported libraries under it's root). This allows us to decide WHEN to update them. In addition there are pland for automating these updates from a special tool for the source control system, so that it is a 10 seconds job to move the O/R mapper, for example, to a later build. Thomas > -----Original Message----- > From: Selke, Anthony [mailto:[EMAIL PROTECTED] > Sent: Freitag, 6. Mai 2005 13:59 > To: Thomas Tomiczek; nant-users@lists.sourceforge.net > Subject: RE: [Nant-users] any suggested strategies for an > environment where new project dependencies are constantly being added? > > I haven't tried to solve this problem and I may be over > simplifying some part of it, but have you considered using > the NantContrib tasks to automatically register your > library/framework binaries to the GAC? If these projects > registered the latest successful outputs to the GAC each time > they ran, then any dependant projects that needed those > libraries would be able to get to the latest version whenever > they were built. > > If the GAC isn't an option, what about copying the binaries > to a common location when each build executes and then > referencing that location when building a dependant project? > Similar idea to the GAC, but you wouldn't have to mess around > with strong names and such. > > Just a thought. > > Tony > > <><><><><><><><> > > Problems get injected as products are coupled - one product_s > output may be used in the next product as input (base > library), especially as, along the product lines, we have an > application framework and an O/R mapper among the products, > having basically a100% reuse rate. > ------------------------------------------------------- This SF.Net email is sponsored by: NEC IT Guy Games. Get your fingers limbered up and give it your best shot. 4 great events, 4 opportunities to win big! Highest score wins.NEC IT Guy Games. Play to win an NEC 61 plasma display. Visit http://www.necitguy.com/?r _______________________________________________ Nant-users mailing list Nant-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nant-users ------------------------------------------------------- This SF.Net email is sponsored by: NEC IT Guy Games. Get your fingers limbered up and give it your best shot. 4 great events, 4 opportunities to win big! Highest score wins.NEC IT Guy Games. Play to win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20 _______________________________________________ Nant-users mailing list Nant-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nant-users
