Organizing Projects

C#Builder project management is performed hierarchically with a project group at the top and one or more projects within a project group. Projects hold the files required for building a library or executable file and project groups are for logical grouping of one or more projects. The Project Manager window (see Figure 5.9) provides all options necessary for configuring and managing projects. This window is used so often that I keep it open in all desktop configurations.

Figure 5.9. The Project Manager window.

graphics/05fig09.jpg

Before getting started with the rest of the information about organizing projects, I just want to point out one very useful productivity enhancer. At the top of the Project Manager, right-click on the title area where it says Files and select Toolbar, which brings up a toolbar on the Project Manager window (see Figure 5.9). On this toolbar there is a combo box, called the Project List box, containing the names of all the projects in the Project Manager. This is set by default to the active project. The real value of the Project List box can be seen with multiple projects in the Project Manager. Imagine that there are 50 projects and every time you need to navigate to one, you have to scroll through the list to find it, which is annoying and a big timewaster. With the Project List box, it is easy to just select the project and the Project Manager will navigate directly to that project automatically.

Because the wizards are so easy to use, they give the false impression that you can just run them and everything will be set up and ready to go. Maybe for a small sample project a wizard is fine, but for anything serious or working on a team project, it is best to plan the project ahead of time. Extensive planning involves taking the components identified in analysis and partitioning them into projects. At a minimum, make sure the directory structure is set up so that the project can be extended in a logical manner.

CLOSING A PROJECT GROUP

To get ready for a new project, you can close the current project group by choosing File, Close All. This will remove the project group from the Project Manager and remove all open files from the editor. If any files need to be saved, a message box will appear asking for Save confirmation options. Choosing File, Close only closes the active file, but the project group will remain open.

First, I'll demonstrate the problem and later show how to do a little planning and the actions necessary to get a project set up properly. To get started, create a new Console Application project, accepting defaults. In the Project Manager, select the new project group and select Save from the context menu. Do the same for the new project that was created. What you end up with are a project group file (*.bdsgroup), a project file (*.bdsproj), and a class file (Class.cs) all in the same directory. Adding new projects to the project group will put the files in the same directory if you accept defaults. After a while, this can get disorganized and hard to manage. Think about all the files in the same directory for a project group with 50 projects. Accepting default names and settings is not the best approach to project management. With a little bit of planning, you can make your projects well-organized and easier to work with.

Project Groups

Project groups sit at the top of the Project Manager window hierarchy and contain one or more projects. Only a single project group can exist at one time in the Project Manager window. When you're planning for a new project, begin with the information required for the project group, which includes a name and location.

When all of the components under a project group will be part of the same application, a sensible name for the project group is the name of the application being built. Other ways to determine the name are like the method I used for listings in this book. All of the projects in the project group were independent entities, so the project group name reflected an overarching name, such as Chapter05, that described the projects as a whole. Because of potential conflicts with third-party tools and utilities, spaces and special characters in the name should be avoided. A good convention is Pascal casing, in which the first letter of each word in the name is capitalized.

Location of the project group is important because it should be easy to find and not conflict with operation of other tools and utilities. As you probably noticed, the default location of project group files is directly under the My Documents\Borland Studio Projects directory. Clearly, a subdirectory is required to keep projects from clashing. The subdirectory should be named the same as the project group name for easy location. Avoid special characters in the filename such as "C:\Projects\Jose'". Although Windows will allow you to add a directory with an apostrophe, C#Builder will get confused and not work with that project.

In addition to common subdirectory naming, every member of the team should use the same path. If you've ever had to sit down with another developer who is having source code problems and try to figure out where his or her projects and files are physically located, you'll understand what a timewaster this can be. However, if directories are set up identically for every developer on the team, problems are resolved much faster.

TIP FOR SETTING DEFAULT PROJECT

If you don't like the default project folder that C#Builder gives you, add the following registry key with the default project directory you prefer:

 HKEY_CURRENT_USER\Software\Borland\BDS\1.0\Globals graphics/ccc.gif\DefaultProjectsDirectory 

Another good practice in project location is to locate project groups off the root directory (usually C:\). When doing so, avoid spaces in the directory names to prevent any problems they have a potential to create with third-party tools and utilities. Create a main projects directory, such as C:\Projects, and put subdirectories for each project group under that. It is easy to find, consistent, and avoids problems caused by spaces in the path. Short directory names are also easy to navigate in file Open and Save dialogs.

CONSISTENCY IS KEY

Just as with coding standards, consistency among team members is important. This applies to management of code projects in C#Builder also. It is best to accept that no standard will be perfect for every situation. There will always be times when the standards don't work in a given situation. In those cases, make alterations as the exception and not the rule. However, a standard way of setting up an environment results in a gain in productivity.

When starting a new application, create only the project group first. You can run the Project Group wizard by selecting File, New, Other. When the New Items dialog appears, select the Others folder in the Item Categories list. Select the Project Group icon and click the OK button. This will create a project group in the Project Manager window with a default name. From the context menu of this project group, select the Save Project Group As menu item. Then navigate to where you want this project group located and create directories as needed. Remember to change the name of the project group to <yourname>.bdsgroup, replacing <yourname> with the name of the project group, before clicking the OK button. This establishes the project group that is now ready for adding projects.

A couple of ways to rename a project group are by selecting Rename from the project group context menu or by selecting the project group in the Project Manager, waiting a second to avoid the double-click and clicking the project group name. This puts the project group name into editing mode where you can change the name. Press the Enter key or click somewhere else on the screen to make the change take effect.

Projects hold files for building an assembly, such as an executable or library (DLL). The Project Manager hierarchy is only two levels deep. There is a project group and below that are a number of projects, all at the same level. Projects may only contain references and files, but not subprojects. Accordingly, there is no concept of a subproject in the C#Builder Project Manager.

Using the same logic as applied to project groups, my recommendation is that project names should not contain spaces or special characters. However, the naming convention is unrestricted and can be whatever you choose.

The location of each individual project should be in a directory under the project group. Although you can place project directories anywhere, such a practice can cause problems and should be the exception and not the rule. Those familiar with Java know that package and class names must correspond to physical file and directory names. However, this restriction does not exist in C#, where a C# namespace, if you recall, is merely a logical concept that prevents name clashes between identifiers.

SHOP TALK
A FEW TIPS FOR ORGANIZING PROJECTS

Because the only option in the Project Manager is to have all projects directly under the project group, I recommend that you create your physical directory structure the same way. The benefits are that every member of the team has the same structure, and fixing configuration management problems will be easier. Understandability between project organization in the Project Manager and the file structure is also enhanced. Think about the confusion of trying to map the difference between the two-level Project Manager structure and a multilevel physical file structure that corresponds to namespaces. Also, consider how difficult it is to fight against a source control tool that wants to manage files a certain way. You could select Show Path from the project's context menu, but this wouldn't necessarily solve all the problems in a team environment. Your Project Manager would look one way, physical files would be laid out another, and who knows what the source control structure would look like. My experience is that, unless you have configuration managers to help with code management, the file structure that maps one-to-one with the Project Manager structure and the source control structure is the easiest to work with.

Other forms of projects include those where there is a master project group with all projects for builds and each developer has a local project group with only those projects they need. Each project is part of the master and one or more developer projects. Another solution is to have multiple project groups specializing on each part of an application. Both of these arrangements are harder to manage, integrate, and build.

Sometimes a library project is used in many different project groups. The physical location of such a project doesn't necessarily belong in the directory structure of one project group. The best way to handle an independent project like this is by specifying a common directory for it so that all team members reference the project the same way.



C# Builder KickStart
C# Builder KickStart
ISBN: 672325896
EAN: N/A
Year: 2003
Pages: 165

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net