Click here to Skip to main content
15,794,850 members
Please Sign up or sign in to vote.
4.00/5 (1 vote)
Morning all,

Theoretical question.

I am attempting to improve the organisation of our solution. Currently we have around a 100 projects in it. These are organised according to namespaces, for example in the following list of namespaces, each would be a project (in this case 6 projects).

I am considering reducing the project count by restructuring this so that there would be 4 projects as follows

With the sub namespaces of Recs.TxnData.Wpf created as folders within the parent project.
So, on to my question

Is there any reason not to do this?
Apart from the obvious benefits (less final binaries, easier to manage projects) are the any other benefits?
I am wondering if this will improve the performance of VS2010 when working with the solution as it is currently a problem (100 projects as mentioned.)

Many thanks.
Updated 14-Jun-11 23:32pm

AFAIK, No, this folder structure will have no bearing on performance.
It will be helpful once this project goes into maintenance though - from a developer perspective.
Share this answer
PaulPrice 15-Jun-11 5:15am    
Hmmm, maybe I should just try it and see what happens.

Project directory structure and name space structure are unrelated. You can use any number of any name space is a single project or same name spaces in multiple projects using each other or not.

You can apply some discipline to it; and it can be helpful, but not required in any sense. Also, please understand that name spaces have nothing to do with accessibility of the types/members, they only define how their fully-qualified names would look. The real purpose of name spaces is to reduce the likeness of name clashes and to add the ability to use the same simple names in different contexts.

Neither directory structure nor name spaces effect performance or any other qualities of the code, ever. Those subjects are totally unrelated.

Share this answer
TRK3 15-Jun-11 20:01pm    
Though they could have some effect on compile / link / intellisense performance. But I suspect that would not be noticeable unless you had a huge number of files in one directory or a huge number of namespaces or a huge number of identifiers in one namespace (whatever "huge" means)...
Sergey Alexandrovich Kryukov 17-Jun-11 22:59pm    
I did not say anything about build or intellisense -- of course it can effect it. A point of huge number of file -- also about build and VS functionality. I think we're discussing only run-time performance, don't we?
TRK3 18-Jun-11 10:43am    
OP did ask "I am wondering if this will improve the performance of VS2010..." It definitely won't affect run-time performance. About the only thing it will affect is VS2010 itself, but I think the best solution is to organize your code the way that makes it easiest to maintain and don't worry about VS performance. If VS is too slow, upgrade your development machine -- it'll save a lot of money in the long run to have maintainable code and a fast development machine.
Sergey Alexandrovich Kryukov 20-Jun-11 1:15am    
Absolutely agree.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900