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 > precedence over the hint > path in the project. So each dev can put the DLL's > wherever they want. > This way if they want to build against a different > version than in the > hint path they can just adjust their reference path > for that project. > Reference paths are stored in the .user files which > you should not be > checking into source control. > > At my shop we have a separate source control (PVCS > Version Manager) > project called CommonBinaries which holds all the > shared DLL's. The > project folder has sub-folders for each 3rd party > (including us) and > within that is a version folder. For example, > CommonBinaries/CrystalReports/v10. Sometimes you > don't need the version > folder, or you can make the version more or less > granular. You could > also have Net1.1 and Net2.0 divisions. > > The builds that create the internal shared binaries > check the latest > version into source control. The 3rd party ones are > of course manually > managed. This way, you don't need every app that > uses common DLLs to > build the common project as well. > > So, my bottom line suggestion is to go with DLL > references for internal > DLLs that are shared by multiple projects. I think > this is the way to > go, and it works for us. > > BOb > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of Eric > Fetzer > Sent: Tuesday, September 12, 2006 11:39 AM > To: Nant Users > Subject: [NAnt-users] Shared Components > > I'm looking for "Best Practices" for components that > are shared among several applications in reference > to > NAnt. First of all, dll or project references. 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. If I go with project references, I have > to > build the shared component inside of the same > <solution> task as I'm building the application, > correct? What I'd rather do is call a .build file > for > each of the shared components telling it what label > to > get the code from and where to put the assemblies > when > it compiles them. However, this only works for dll > references because a project reference won't be able > to resolve the GUID. Any advise would be very much > appreciated, we're getting A LOT of shared > components > going and it's getting pretty confusing the way I'm > doing it right now. > > Thanks, > Eric > > __________________________________________________ > 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 > __________________________________________________ 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
