The big benefit to the project references is that you can step into the code. Log4net, we definitely wouldn't want to do that with, but it can be helpful for these in house projects...
--- Rod Ayers <[EMAIL PROTECTED]> wrote: > A great, helpful discussion.... > > I absolutely agree with the concept of treating > "internally-created" > assemblies/dll's in the same way as we would > "third-party" stuff. It's > a powerful concept, though I've known developers who > seem to get really > confused by the idea! > > Rod > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of Bob > Archer > Sent: Tuesday, September 12, 2006 11:29 AM > To: Eric Fetzer; Nant Users > Subject: Re: [NAnt-users] Shared Components > > 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, > === message truncated === __________________________________________________ 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
