Actually Bob, I found a better article on this: http://msdn.microsoft.com/practices/compcat/default.aspx?pull=/library/en-us/dnbda/html/tdlg_ch3.asp
In my case, we have 7 or so shared projects that several of our applications use. The thing is, as these shared components evolve, we don't want to blindly take new versions (i.e. if we're in the middle of a test cycle, we want to stick to the same version, yet may need to continue builds). So in the build, for shared projects, I check out by label. Also note that I'm opposed to checking in our own assembleys (why do that if I can build it?). I put third party dll's in an "External References" folder, but I'd rather not do that with our own stuff. Not that this mandates project references, that was forced elsewhere. And prior to now, we used dll references in the exact same situation just fine. I guess the only point is, I was able to make project references work. Thanks for your input! Eric --- Bob Archer <[EMAIL PROTECTED]> wrote: > Do you have a link to that article? > > He is absolutely right. When multiple projects are > in a single solution > using a project reference is the best way to do it. > But, having all have > to get all source to common projects and needing to > rebuild that project > is a pain. Or course, there is an advantage such as > if you want to debug > into the common code. > > As said above, I think in relation to a specific > solution you should > treat commonly shared DLLs that are created > internally separate just as > you do with third party DLLs. If you were using > log4net you wouldn't add > all the source code projects to your solution, > right? You would just add > a DLL reference. > > Also, if you are using VB.Net the more source code > you have in the > solution the slower things will go. This is due to > the background > compiler. We even pulled a project that was specific > to our app out of > the solution and use a DLL reference. This is the > project with all the > typed data sets. There is so much code in it that. > But, since it isn't > change to often we prefer to not have the background > compiler chew on it > every time we open our solution. > > Anyway, whatever works best will be fine. Keep in > mind, a project can > reside in multiple solutions. So, you can have > solutions that you use > for your build system and other solutions that your > devs use. Of course, > if you are not using the solution task it doesn't > really matter. > > In my opinion though the important issue is to > ensure that the > versioning and building of the "common" stuff is > kept separate from the > applications that are dependant on it. But, some > people like to have the > developers and the build server run the same build > scripts. I personally > never found that necessary. > > Remember, if it were easy, everyone would be doing > it. > > Bob > > > -----Original Message----- > From: Eric Fetzer [mailto:[EMAIL PROTECTED] > Sent: Tuesday, September 12, 2006 2:12 PM > To: Bob Archer; Nant Users > Subject: RE: [NAnt-users] Shared Components > > Actually, John Mischel at Microsoft put out an > article > entitled "Project Structure Best Practices" where he > said (note paragraph 2): > > There are several different ways that you can > structure your solutions and projects. The most > common > method is a single solution that contains multiple > projects. This model works well for small and > medium-large systems that consist of one or more > project assemblies. It allows each member of your > development team access to all of the projects in > the > solution, allowing them to build and deploy the > entire > solution on their local workstations. The > single-solution has the following primary advantages > and disadvantages: > > When you need to reference another assembly > generated > by a separate project, you can use a project > reference. Project references are the preferred way > to > establish references to other assemblies and they > are > guaranteed to work on all development workstations > in > a team environment. In addition, because project > references are sensitive to changes in the > configuration of the referenced project, you can > automatically switch from Debug and Release builds > across projects without having to reset references. > Assembly versioning issues are avoided, because > Visual > Studio .NET detects when a client of a referenced > assembly needs to be rebuilt. > The system build process and build script is much > simpler. > The model scales only so far. If you want to work on > a > single project within the solution, you are forced > to > acquire all of the source code for all projects > within > the solution. > Due to project dependencies, even minor > (non-breaking) > changes to a single source file within a single > project can result in a rebuild of many projects > within the solution. If an assembly's interface > changes within a referenced project, you want the > client project to be rebuilt. However, unnecessary > rebuilds can be very time consuming, especially for > solutions containing many projects. > > > --- Bob Archer <[EMAIL PROTECTED]> wrote: > > > MS has a white paper on this at > > > http://msdn.microsoft.com/practices/compcat/default.aspx?pull=/library/e > > n-us/dnbda/html/tdlg_rm.asp > > > > And they list several ways of structuring a > project. > > But, no where do > > they say which one is "best"... the basically say > it > > depends on your > > project and circumstances. > > > > BOb > > > > > > -----Original Message----- > > From: Eric Fetzer [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, September 12, 2006 1:43 PM > > To: Bob Archer; Nant Users > > Subject: RE: [NAnt-users] Shared Components > > > > Thanks for your reply Bob and Rod! > > > > We've got a new twist that developed in a meeting > > this > > morning. We're moving over to project references > > only. The lead architect here is insistent > because > > Microsoft considers this "Best Practice". From a > CM > > perspective, this makes it tougher in reference to > > shared projects, however. So here's my plan I > > guess: > > > > Each one of the shared projects will have it's own > > build which will check out the code (based on the > > label set in the parent .build file) and build > > relatively from the build.dir also set in the > > parent.build file (.\project.name). Then when a > > project is dependant on that project, I'll use > > <referenceprojects> to point to the csproj file > > that's > > referenced. > > > > Can anybody think of a better way to do this? > > > > Thanks, > > Eric > > > > --- Bob Archer <[EMAIL PROTECTED]> wrote: > > > > > > If I have dll references, I have to get all of > > the > > > developers to keep > > > these components in the same place as I keep > them > > > for the build so that > > > the hint path resolves. > > > > > > My first comment is having all your devs use the > > > same directory > > > structure is actually a good thing. It makes > > source > > > control much easier > > > for one. It also helps when devs pair so they > know > > > where everything is > > > no matter what PC they are working on. > > > > > > Secondly, this comment is not true. In Visual > > Studio > > > the users > > > "Reference Path" settings for a project take > === message truncated === __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ NAnt-users mailing list NAnt-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nant-users
