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