There's been some interesting discussion on having too much in your App_Code folder as well as dealing with solutions holding large numbers of projects. I find it pretty amusing that some folks are complaining about performance in Visual Studio when they're working in solutions containing 50 to 70 projects.
50 to 70 projects? That's Just Plain Bad for any number of reasons. First, you're definitely degrading your build times in Visual Studio. Secondly, you're probably killing your performance in Visual Studio as Guthrie mentions in his post.
More important is the impact on your ability to keep your head wrapped around what's going on with your code. My initial query to folks running solutions with that many projects in them runs along the lines of "What the hell are you thinking?!?" It's nuts to have that many projects wrapped in to one solution. How in the world are you going to be able to wade through all that code and keep everything straight?
Do yourself a favor and look hard at breaking out chunks of those projects into sensible blocks of separate solutions. Worried about dependencies between components you've broken out into different solutions? Use NAnt or MSBuild to manage your build process and keep all those dependencies straight. (You ought to be using one of those anyway, especially for larger systems!)
Sure, there are edge cases where something really funky might force you to work with a silly number of solutions in one project -- but those are few and far between. Do your work up front and think how such a massive system should be laid out. Do your refactoring as you work and move out logical chunks of functionality to external libraries.
Your life will be much simpler and you'll have better performance in your development environment.
2 comments:
Jim,
I commented on Hanselman's blog that I recently worked on a solution that consisted of more than 90 projects. Unfortunately, I had nothing to do with the structure of the project and would have definitely done things differently.
As a contractor working on the project (and coming in relatively late in the development cycle), I had an extremely difficult time working in the project, much less understanding it. :-) I also ended up having issues building the solution which everyone blamed on my hardware (dual core with 2GB of RAM). Go figure.
Sheer insanity, Michael! It takes some serious brass tacks to point to hardware as a build problem when you're running a solid system like that. God forbid those folks take a look in the mirror first...
Post a Comment