Got a Win7 box with VS2010 Premium installed on it. Building desktop apps works just fine. But we got this solution with 15 SL4 and 21 desktop projects... Building the SL part of it takes too long. This is very irritating and encourages to drop TDD since every time I run a test it takes ~3 seconds for msbuild to find out that nothing changed and the project should be skipped. The projects are very small and there's nothing fancy in them and we hadn't any problems before we switched from VS2008+SL3. I've heard people complaining abound VS2010 speed in general, but nothing about SL4 build time. Is anyone experiencing same problems and is there any workaround for this?
A:
Do you need that many projects? As a rule of thumb, less is better. You say that the projects are very small, that would be an indication to me that you probably don't need that many.
Don't use it for managing dependencies (cycle avoidance). If you're trying to manage 'units of development' or logical groupings, use namespaces instead.
Physical/project separation is good for keeping test code out of production code, and managing units of deployment, but don't separate it until you're getting something out of it.
Patricks Smaccia wrote a good article on when and when not to create assemblies.
Another way to tackle the problem is to break your solution up into multiple solutions, and use references to the dlls produced by the other solutions. That way, you only build part of it at a time. If you need to work across many dlls at the same time, this is inconvenient, but it's a sign that something is likely to be wrong with the design of your code.
This post on speeding vs.net up with many projects may also help.
FrederikB
2010-06-07 08:27:47
Thank you for the link. Gonna read it right away. But still, I find it unacceptable for build to take so much time and would like to know about possible workarounds without having to merge projects. I have to admit that in this case we don't need so many assemblies - this piece of software is kind of technology evaluation for us. And it is possible that in next projects we will have to modularize the solution extremely (plugin architecture)
adlanelm
2010-06-07 08:57:03
Are you running Code Analysis? One thing we did was to create a build configuration that has no code analysis. This allows us to build much quicker. This work quite well when doing TDD.With a plug in architecture, you definately don't need to keep everything in a single solution. It's probably worthwhile having individual solutions for each plugin, referencing the core assemblies. If you have a body of standard plugins, keep those in a single project. YMMV, of course.Added an extra link to the answer for some other tricks you could try.
FrederikB
2010-06-07 09:12:57
Code Analysis was first to blame and disabling it was the very first thing to do. I already tried the tricks found on this site - no significant change. As I mentioned the project is mostly a technology evaluation and as such it is very volatile - it helps to have everything in 1 solution. We could split the thing into multiple solutions, but having to recompile each related solution manually is IMO ineffective and error prone. Yes, I have already tried to automate the build process, but RIAServices keeps getting in the way. Thank you for your effort anyway.
adlanelm
2010-06-07 09:48:16