Hi, this is pretty much the same problem as I had :) Our solution is as follows (and comes straight from one of the Ms solution development centre (SDC) who we had in for consultancy on precisely this problem so I guess they use it too):
* System Solution containing all projects - used for daily (overnight) builds * Subsystem Solutions containing _project_ references to all projects required by the subsystem * [1]In each subsystem solution have a debug build that only builds the projects in that subsystem and doesn't rebuild the referenced system. * In each subsystem solution have a NUnit build that only builds the project files required for the unit tests and runs the tests. * Strict design rules about which subsystem can reference another. * A coffee machine that takes 1/2 hour to make 1 cup of coffee for when you really do have to build everything ;) The problem with file references is that it is very hard to make sure you are referencing the correct build (debug/release) and if you bump the build numbers daily this can also lead to issues. Don't keep binaries in sourcesafe. VSS can't tell the difference between 1 binary and the next so it stores the ENTIRE file every time you check it in. VSS has real problems when it gets over 4gb and daily builds (or more often if you run the script on demand) will chew up 4gb in no time at all. I use buildit with a slightly modified config file to build the entire solution on dev boxes overnight/on demand and use the coffee machine at this point :) The advantage of using the different build configurations is that Buildit (and possibly Nant) can build them too. This is particularly good for doing a nightly Nunit build and running the results to file so you can check that not only do you have a build but it smoke tests and unit tests ok as well before doing a final build for deployment to staging without unit test code or even as release. It does take time to get this setup and working properly but it is well worth it. But you already know that. Hope this helps James [1] I have assumed that you are familiar with managing your own build configs using the configuration manager, however in case you haven't used it right click on the solution and choose configuration manager. Use the active solution configuration dropdown to create a new build config for the solution. Use the new option in the configuration column to create a new build configuration for the selected _project_. You will need to do this for projects that you don't want to build in this config as well so you can uncheck the "build" option otherwise visual studio will leave the project on its current build. You can then quickly change which build you want in the toolbar if you want. -----Original Message----- From: Jesse Sanders [mailto:[EMAIL PROTECTED] Sent: 27 July 2004 17:59 To: [EMAIL PROTECTED] Subject: [ADVANCED-DOTNET] Large solutions and references All, I am the technical lead on an application with ~216,000 lines of VB.NET code with 4 developers. The solution currently consists of 61 projects, all loaded at once with project references. The solution can be logically divided into 7 subsystems where each subsystem consists of web, business, data, interface, NUnit, and NUnitASP projects (6 separate projects). There are ~20 helper projects used by the subsystems (MVC, MS DataAccessLayer, Event Logging, etc). The obvious problem that arises is that compiling entire project takes too long. When we originally started this project, we had to switch to this reference model because we experienced too many problems going with straight local file references. This problem was largely caused our inexperience with .NET referencing issues. Now we find it cumbersome to load 61 projects and compile all of them each time we run the application in debug mode. The proposed idea is to use project references within each subsystem and use file references for references external to the subsystem. This would allow developers to load just the subsystem they are working on which would reduce the number of projects loaded from 61 to about 6. After reading several of Microsoft and DevX articles on the subject, this seems to be the best solution to our problem and would make this more manageable. We are setting up a build server to build all the projects every night (on demand as well) and then the debate comes up about what to do with the build files. I am leaning towards taking the debug build and adding them to VSS (check out, copy, check back in), so that the file references will be local for each developer and they will get latest from VSS on the build folder to get the latest version. On the other hand, I could host the build files on a network share and point the file references to that share. The reason I am leaning towards going local with the files is that I have noticed that VSS will allow a developer to step into a file referenced debug build of a DLL. This makes life easier for developers to debug code when crossing subsystems or accessing one of the helper DLLs. Any reason I shouldn't do this? The articles I have seen all point towards using the network share, but if I can help my developers debug across the subsystem, then I think it would be to their benefit. Am I going about this the right way? Does anyone have real world experience working with a solution this large with lots of cross subsystem dependencies? Any insight on the subject is appreciated. As for the builds, I am proposing that we use BuildIt or NAnt to perform the nightly builds. Does anyone have any thoughts on how to manage the build order with a solution this large? Any thoughts on one build tool over the other? I miss the old days of vb6 when you made your reference and if the project was loaded, you could step right into it... but then again, I don't miss DLL hell and registry problems... LOL Thanks, Jesse =================================== This list is hosted by DevelopMentor(r) http://www.develop.com Some .NET courses you may be interested in: >>> Error in line 15 of ADVANCED-DOTNET.MAILTPL: unknown formatting command <<< -> .NET Architecture and Design: Designing Distributed Applications with <- =================================== This list is hosted by DevelopMentorŪ http://www.develop.com Some .NET courses you may be interested in: Essential .NET: building applications and components with CSharp August 30 - September 3, in Los Angeles http://www.develop.com/courses/edotnet View archives and manage your subscription(s) at http://discuss.develop.com
