Hi, Eric.... Sounds OK at first blush...assuming you're getting everything you need for all possible "shared projects">
Rod -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eric Fetzer Sent: Tuesday, September 12, 2006 10:43 AM 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 ------------------------------------------------------------------------- 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
