Our current solutions/projects have several classes combined into one file, I'm told this was done due to the slow compile times in VS.
Is this a confirmed problem and solution?
Can we break these apart now that we are using VS2008 Team system? Has anyone else separated the classes into different files and still had good performance?
I'm using C# rather than VB.NET, but I never encountered compiler performance problems. It seems that this is some kind of premature optimization. I don't care how long my build server needs to build the application. Don't sacrifice clarity for build time performance.
Sounds like you might want to try to persuade your team to look into the solution design; it might not be optimal to have one giant solution with all projects in there. If build times are indeed a problem, I would rather solve it by breaking the solution down to logical parts, if possible.
I do not believe that grouping many classes into a single file will significantly improve build performance for normal projects. It should be safe to break them out into more files (one-per-class is standard).
The one exception I've run into is "Web Site" projects. I don't have any scientific data, but these do seem to get slower as the number of files increases. To fix that you can convert it to a "Web Application" project.
Having too many projects in a solution is also known to make VS slow, but that doesn't sound like your problem.
What is your hardware like?
The big bottleneck with VS is that it needs to read and write loads of little files.
A fast hard drive or two can improve performance loads!
This is a confirmed problem and a confirmed solution. At Tech Ed this year they said that it will no longer be a problem in VS2010, which you could download a beta of and try out.
I work on the VB.Net IDE team and I can tell you that putting everything in 1 file will make VS run slower, not faster. VB.Net works just fine with classes in different files.
The only time this would ever make a difference is if you had an unbelievably slow hard drive, and files that were on very different parts of the physical disks (resulting in more and longer seek instructions). In general this shouldn't be a problem and for the VB.Net IDE this would only be a problem during initial startup. We have several layers of caching that would help eliminate even these types of problems.
You may be able to discover some minimal benefits to this approach if you only consider the raw time it takes the command line compiler to operate. IMHO, the more important numbers are the respnosiveness of Visual Studio and the relative build time for Visual Studio. VS responsiveness will decrease if have extremely long files (which is what will eventually occur if you put ever class into a single file).