Gal Ratner
Gal Ratner is a Techie who lives and works in Los Angeles CA and Austin TX. Follow galratner on Twitter Google
Never break the build again with an organized code base

During my time developing for different companies one of the most common daily scenarios I encounter is helping a developer debug code. Going to some method’s definition, only to realize they can only view metadata and not actual code. The library is still internal, most likely developed by another department inside the same organization, however, it was added as an external DLL reference and to view the code they need to open another solution in another folder. Well this will work until the external code has been updated and since code is updated daily, the references must also be updated or the code base quickly goes out of sync, not to mention debugging the external binaries is very difficult.

When possible, I always try and consolidate code. Keeping code in the same solutions or folders makes it easier to track changes and cascade refactoring. Working with two or three instances of Visual Studio just to see the code used by one project can be eliminated if all the code was already available in the solution you are working with.

The following technique for sorting out and arranging your enterprise code is recommended by me in order to maintain multiple systems with the same common code, making it easy to develop, maintain and produce successful builds.

To consolidate the code you need three main folders

Main/ The main folder contains all the code your organization produces.
Bin/ This is the global bin folder. All of the binary DLLs you compile will be added to this folder. To set it you need to navigate to the properties of your library project and set the output path.

Lib/ This folder contain the master copy of any external DLLs or components you buy or download. When a project need a reference to an external DLL you do not have the code for, you can grab a copy to be placed in the local project’s Lib folder and add a reference to the local DLL.

Place all of your code in Main/ and create a solution file called master.sln. Add all of your projects to this solution. Every time you create a new project, it must be added to the master solution. The master solution must be successfully compiled at all times and the continuous build server must notify the team if the solution or the build are “broken”.

Next you must arrange the global build order. Remove any references that are DLL references or 3rd party components that are not GACed from your references. Add project references. Start with the lowest layer and work your way up. When you are done all projects that do not belong to your UI layer will have references to other projects in the Main folder. Now that you have added all the references you can check what project needs a reference to an external DLL. Create a folder named Lib in the project and add a local copy of the external DLL. Add a reference from the references section of the project to the DLL in the Lib folder you just created. This will allow deployment of the project from any build server without the need to find a copy of the DLL. It is in essence a part of your project.

After you have done that your master solution is ready to be built. It might take a while to compile and that’s ok. You will rarely work with the master solution. Its job is primarily to keep all the code in ready state.
It is now time to create all of the solutions you will be working with. I usually create one solution per logical product, for example, my CDN system can be in InvertedSoftware.CDN.sln and my media processing system will be under InvertedSoftware.Media.Services.sln they both have code that is unique to the project. For example: The UI layers and some of the business layer and code that is common, for example: the libraries InvertedSoftware.Common and InvertedSoftware.Common.Net I usually divide them according to the following diagram:

Now that you have all of your solutions in place you have access to all of the code you need if you are concerned about developers seeing code they are not authorized to see you can restrict the main repository from ever showing the code to developers that are not authorized to see them or use another repository for sensitive code development. In that case you can still use a reference to an external library contain the sensitive code.
Organizing your code is such a way that allows developers to follow references and have projects rely on other projects instead of DLL references will help you better coordinate development around multiple projects and minimize code duplication not to mention you will always have a working complete code base.

Shout it

Posted 5 Mar 2011 2:56 AM by Gal Ratner

Powered by Community Server (Non-Commercial Edition), by Telligent Systems