I have Delphi Project Group (aka Solution in VS.NET) that have 153 projects and it’s not slow at all, I really have to think again about my transition in VS.NET

Separate each group of related projects in a solution folder. Then unload unused folders currenty by you. Use PowerCommands. It is very usefull.
Note:
1- Do not add reference to projects, but add reference to a dll from a hard disk shared folder for a project already exist in the solution to allow debug. Like this you can even unload shared projects and reload them if you want to modify them with any depth.
2- WcfSvcHosting is very bad. It compiles all wcf, dal and entity even you did not modify them. In this case keep maximum 5 wcfs with dals and entities project loaded and unload others to get the solution with 100s projects run in one second.
I have Q6600 with 4GB RAM
3- Do not use CodeRush
4- Do not use more that one IntelliSense. Disable Visual Studio IntelliSense if you use another one that both of them will parse the whole solution and even the framework.
5- Put the solution in a separate hard drive than the OS and the swap file.
6- Use Core to Quad processor and Compile 8 projects simultanusly.

Sorry from my miss spelling if any.

a) add a solution folder (right click at the top in solution explorer and select add->new solution folder) which will tidy thing up a bit, or

b) if you’re concerned about compilation time copy all you DLLs from your big project that don’t change into a Project/BinRefs folder of your small project and reference those. By the sounds of it this is what you “really” want. Of course all your little projects in the big solution should have their own versioning first otherwise you’ll lose where you are.

Don’t get me wrong I’m all for the odd bodge but I reckon b) is a nicer bodge

I like the idea to split stuff into multiple solutions, although that makes every ’svn update’ more expensive, because I would have to compile all the other solutions first. But with a nice msbuild script that can be solved.

The way we get around dependencies is to use a shared folder on the network which each developer has access to. Whenever a project is changed, it is rebuilt and the dll is copied to this shared folder (its all automated).

Each project has file references to DLLs of its dependencies (instead of project references). This allows everyone to have the latest DLL available as a reference when they build their project/solution.

when someone new joins the project, we tell them to use the EMS_NewArchitectureOnly.sln solution, and if it doesn’t compile, run the local build bat file which simply does an msbuild of the entire solution. After that, it just works… we don’t need to wrestle with reference locations at all.

A better solution may be to properly version and separate everything. Create a separate EMS solution, and add a reference to the CMS dlls as needed. If you need to change the CMS code, build a new version and update your reference in EMS. Alternatively, if these are really part of the same product, keep them in one solution, but refactor to have less projects. For example, combine the Common class libraries into one of the others. Only physically separate a project if there is a real functional need. Use namespaces/folders for logical separation of code.

One great way to make this even easier is to put any file references (ie dlls that don’t live in Program Files or the GAC) in an empty project named “_FileReferences”. Set it to not build in any build config (rt click solution -> Build Configurations). Then, when adding a reference, add it from that location. This way, a developer can just get the solution from source control, build, and run. This adds some size to the solution, but is much easier than wrestling with reference locations, etc.

in what situation? if you’re trying to build the smaller solution in Visual Studio (which uses MSBuild) without having built the complete one, it fails… like i mentioned in the post

but if you’ve built the larger solution before using the smaller solution, it works

Track back from DotNetLinks.net…