We're actually just now going down the NAnt path for build automation. Automated builds are the only way to go for large projects - of that there's no doubt. If the build can also re-gen your technical document via NDoc, run your tests via NUnit, and talk to your source code control provider (SourceGear's Vault) then things are even better. Fortunately NAnt does all of these.
Separate from the build process though is the debug process - this is (in many ways) more important, as it needs to be easy for developers to track down and fix problems. For this, I think we're going to go down the "Build all the DLL's, and copy them and their PDB files to a known location" route. For debugging, developers will have a decent knowledge of the source tree layout, so that they can load the right source-code files in, and set breakpoints in the right places. This would be *much* easier if they could actually have the relevant projects loaded into their solutions, but it doesn't look like that's going to work out. I am still stuck at "VB6 could do this, why can't VS.NET??!!". Ah well. -- Chris Mullins -----Original Message----- From: Ben Kloosterman [mailto:[EMAIL PROTECTED] Sent: Thursday, June 03, 2004 3:59 PM To: [EMAIL PROTECTED] Subject: Re: [ADVANCED-DOTNET] Large Solutions (100 projects) and Team Development with VS.NET Why not use nmake and makefiles ? You have much more control that way. Ben > -----Original Message----- > From: Unmoderated discussion of advanced .NET topics. [mailto:ADVANCED- > [EMAIL PROTECTED] On Behalf Of Chris Mullins > Sent: Friday, 4 June 2004 8:51 AM > To: [EMAIL PROTECTED] > Subject: Re: [ADVANCED-DOTNET] Large Solutions (100 projects) and Team > Development with VS.NET > > The only problem with this approach is that it doesn't let you debug the > "whole" project at once - only the subset of files that you have loaded > into your "small" solution can be effectively debugged (breakpoints set, > etc) at any given time. > > This is my fallback solution - I'm still hoping for a way (although it's > looking less and less likely) to be able to effectively debug the entire > thing at once. > > -- > Chris Mullins > > > -----Original Message----- > From: Ertan Tike [mailto:[EMAIL PROTECTED] > Sent: Thursday, June 03, 2004 3:17 PM > To: [EMAIL PROTECTED] > Subject: Re: [ADVANCED-DOTNET] Large Solutions (100 projects) and Team > Development with VS.NET > > We have many projects too as you say. > This is our way; > > Create a directory (i called this is c:\pack) > Create a virtual disk ( subst s: c:\pack ) (programmers can mount any > directory that he want, but drive must be S: ) > Make your all project references to S: drive. > Create little solutions with same types of project. > > When you build a project copy output to pack directory. ( actually i > split > binaries to client and server directories) > For debug builds you must copy .pdb file too. > > Run it from S: drive and use attaching the processes and break points. > If you place pdb files correctly you can even use stepping in debug mode > projects. (even different solutions) > > This is working good for every programmer without cries and screams :) > > -----Original Message----- > From: Unmoderated discussion of advanced .NET topics. > [mailto:[EMAIL PROTECTED] Behalf Of Chris Mullins > Sent: Friday, June 04, 2004 1:06 AM > To: [EMAIL PROTECTED] > Subject: Re: [ADVANCED-DOTNET] Large Solutions (100 projects) and Team > Development with VS.NET > > > Frans Bouma Wrote: > > [Big Solutions] > > > You shouldn't load one of the 50 stable projects into the main > > solution, you should reference debug builds of the stable > > projects from the main solution projects and copy hte .pdb > > files into the debug bin folder of the main solution. > > That's actually what I'm doing now. This works (as you say) quite well > for stepping into source code. > > Unfortunately, what this doesn't allow is for me to pull up the > source-code to a particular data layer class, set a breakpoint, hit F5, > and eventually stop at the break point. > > There are enough layers of business entities in between the data layer > and the entry point that actually trying to single-step into the code > just isn't at all practical. Breakpoints are a must... > > The other thing that I tried was attaching 2 debuggers to the process > that I'm running. One of the debuggers would have the "unstable, often > changing" projects, and the other debugger would have the "stable" > projects. Unfortunately, I can only attach a single debugger to a > process. > > -- > Chris Mullins > > =================================== > This list is hosted by DevelopMentor. http://www.develop.com > Some .NET courses you may be interested in: > > NEW! Guerrilla ASP.NET, 17 May 2004, in Los Angeles > http://www.develop.com/courses/gaspdotnetls > > View archives and manage your subscription(s) at > http://discuss.develop.com > --- > Incoming mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.692 / Virus Database: 453 - Release Date: 28.05.2004 > > --- > Outgoing mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.692 / Virus Database: 453 - Release Date: 28.05.2004 > > --- > Outgoing mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.692 / Virus Database: 453 - Release Date: 28.05.2004 > > =================================== > This list is hosted by DevelopMentor(r) http://www.develop.com > Some .NET courses you may be interested in: > > NEW! Guerrilla ASP.NET, 17 May 2004, in Los Angeles > http://www.develop.com/courses/gaspdotnetls > > View archives and manage your subscription(s) at > http://discuss.develop.com > > =================================== > This list is hosted by DevelopMentor(r) http://www.develop.com > Some .NET courses you may be interested in: > > NEW! Guerrilla ASP.NET, 17 May 2004, in Los Angeles > http://www.develop.com/courses/gaspdotnetls > > View archives and manage your subscription(s) at > http://discuss.develop.com =================================== This list is hosted by DevelopMentor(r) http://www.develop.com Some .NET courses you may be interested in: NEW! Guerrilla ASP.NET, 17 May 2004, in Los Angeles http://www.develop.com/courses/gaspdotnetls View archives and manage your subscription(s) at http://discuss.develop.com =================================== This list is hosted by DevelopMentor� http://www.develop.com Some .NET courses you may be interested in: NEW! Guerrilla ASP.NET, 17 May 2004, in Los Angeles http://www.develop.com/courses/gaspdotnetls View archives and manage your subscription(s) at http://discuss.develop.com
