Hi, Eric.... I've got a couple of variations.
For one, we have an "Assemblies" folder in VSS, and I can get from their. It's a little not neat, because I have to do a setup each Build separately. Also, I've found that Developers don't keep the shared folder current...or they make minor tweaks for their app, that don't apply generally. That makes a real mess out of "common/shared". What I did do was to create a local Assemblies folder under the Build folder. I used VSSGet to get the required shared assemblies folder from VSS, and put them in the local shared assemblies folder under the Build folder. I usually try to run with a set of "locked down" Build files...my personal copy of all the solution and .*proj files. That way I can set the references when I take on the Build, and they stay put. In this case, I kept my Build files in a separate folder under the project in VSS. Then, after I did the "get", I would copy my copy of the Build files over top of the code, so I always knew what I was using for the Build. And all the Builds were clean. Developers only needed to tell me if they made changes to the project or solution files, and that was rare once a new app got settled in. I've tried just getting the Assemblies from the VSS Assemblies folder, and having a local common assemblies folder. That kind of works, too, but I sometimes get crossed up with what the Developers do. More recently, I have a Build that has several shared assemblies, some for this project, some for that. In this case, I created an Assembly project (.vbproj), put all the assemblies in it, made the references relatively to the Assemblies project, and excluded the Assemblies project compile from all configurations (Development, Release). That's worked pretty well, since .Net knows to actually retrieve them from VSS and the Developer Builds work fine, and I get them easily, too. Things would be somewhat easier if every developer didn't have at least three different ways of structuring their local Build areas. I would prefer to run all shared/common assemblies from one folder, and handle the relative pathing when I set up the Build. But our Developers aren't quite that disciplined yet about a true common/shared folder. Rod -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eric Fetzer Sent: Tuesday, September 12, 2006 8: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
