Namespaces combined with TFS / Source Control explanation
- by Christian
As an ISV company we slowly run into the "structure your code"-issue. We mainly develop using Visual Studio 2008 and 2010 RC. Languages c# and vb.net. We have our own Team Foundation Server and of course we use Source Control.
When we started developing based on the .NET Framework, we also begun using Namespaces in a primitive way. With the time we 'became more mature', i mean we learned to use the namespaces and we structured the code more and more, but only in the solution scope.
Now we have about 100 different projects and solutions in our Source Safe. We realized that many of our own classes are coded very redundant, i mean, a Write2Log, GetExtensionFromFilename or similar Function can be found between one and 20 times in all these projects and solutions.
So my idea is:
Creating one single kind of root folder in Source Control and start an own namespace-hierarchy-structure below this root, let's name it CompanyName.
A Write2Log class would then be found in CompanyName.System.Logging.
Whenever we create a new solution or project and we need a log function, we will 'namespace' that solution and place it accordingly somewhere below the CompanyName root folder. To have the logging functionality we then import (add) the existing project to the
solution.
Those 20+ projects/solutions with the write2log class can then be maintained in one single place.
To my questions:
- is that a good idea, the philosophy of namespaces and source control?
- There must be a good book explaining the Namespaces combined with Source Control, yes? any hints/directions/tips?
- how do you manage your 50+ projects?
