In the near feature we will start the next phase of the migration of our old system to dotNet. We already ported a lot of the functionality, but the next phase will at least triple the size of the .NET codebase.

We already refeactored the system into 5 separate solutions: 1. The LLBLGen generated code (about 240 entities) 2. A application framework containing common functionality 3. The business functionality (about 90 manager objects and 200 "Workflows") 4. A webapplication (250 webfoms, and some service objects to collect the data from the DAL). 5. A windows service for scheduling background processes

The partioning is such that in most cases only a single solution has to be modified. A developer thus can get the latest version from sourcesafe, make his modifications and check in again.

I expect that in the near feature: - amount of entities will grow to about 400 - webapplication: some 800 webforms will be added - at least 20 webwervice-methods need to be added - about 300 manager classes are neccessary

That was a long intro, now the questions:

1. What do you think the maximum amount of classes is that you can keep manageable in a single project/solution?

2. Is there a way to refactor this into smaller solutions without losing the ability to work in a single solution most of the time?

1. What do you think the maximum amount of classes is that you can keep manageable in a single project/solution?

As many as you wish, you can always use folders to group your classes and make the navigation and maintainance an easy task.

1. Is there a way to refactor this into smaller solutions without losing the ability to work in a single solution most of the time?

I think refactoring into smaller projects is not decidable upon the unumber of files but rather with the nature of those classes. If some classes share the same goal, responsibilities and may be used within different projects, then you can encapsulate them into some class library.

1. What do you think the maximum amount of classes is that you can keep manageable in a single project/solution?

As many as you wish, you can always use folders to group your classes and make the navigation and maintainance an easy task.

It is not only about navigation, but also about performance. It takes already quite some time to load the solution in VS2003.

1. Is there a way to refactor this into smaller solutions without losing the ability to work in a single solution most of the time?

I think refactoring into smaller projects is not decidable upon the unumber of files but rather with the nature of those classes. If some classes share the same goal, responsibilities and may be used within different projects, then you can encapsulate them into some class library.

That's true, but i was not thinking about smaller projects, but smaller solutions. I don't want solutions that need 5 minutes to load and 10 minutes to compile. On the other hand, i do not want to have to open/edit/compile multiple solutions to accomplish a single functional task either.

At least with VS 2005 there are lots of performance problems with large solutions. There are some hotfixes out that address some of the problems, but even with these installed it is a pain working with bloated solutions. Maybe you can refactor your generated project by domain and only include the generated classes that are necessary for what you are working on?

[quotenick="wvnoort"]

It is not only about navigation, but also about performance. It takes already quite some time to load the solution in VS2003.

VS2003 has big problems with large solution files. You should look into using NAnt to create a build script for starters. Once you have a NAnt script you can then use CruiseControl.NET to do continuous integration, but that's another topic entirely .

Also, you may want to put projects that are rarely updated in a separate solution, then compile them and add their assemblies to a folder that you can reference them from in your other solution, the one that you really need to update and work in on a daily basis. It depends upon the type of app you're working on of course.

[quotenick="Chester"]

wvnoort wrote:

It is not only about navigation, but also about performance. It takes already quite some time to load the solution in VS2003.

VS2003 has big problems with large solution files. You should look into using NAnt to create a build script for starters. Once you have a NAnt script you can then use CruiseControl.NET to do continuous integration, but that's another topic entirely .

I already made a series of nant scripts for the nightly build and deploy to our test servers. It would be nice to have an alternative to VS that offers source editing with intellisense, but without all the additional features.