> 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 ------------------------------------------------------------------------- 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
