Conditional Compilation

Chapter 17. Version Control

Change is inevitable. Creating computer software is more like growing a garden than manufacturing a widget. Although a distributed program file is a static entity, the program itself usually changes even adapts over the course of its life. Developers usually change a program to correct problems or improve usability, for example. When developers stop enhancing a product, it's often abandoned by users who switch to tools that are more in line with current business paradigms. It's a simple fact that you must improve your product or lose your customers. Although this constant change is good for users (and good for your bottom line), it creates a number of challenges for developers and project managers.

Projects in Microsoft Visual Basic .NET are complex entities, often composed of dozens of source files. In addition, most projects make use of third-party components and are distributed through the use of dedicated installation programs (or by creating a setup project in Visual Basic .NET itself). As you make changes and distribute new versions of a program, it becomes exceedingly difficult to keep the entire process moving forward. For example, have you ever inadvertently compiled an older version of a form in a new build and ended up breaking what was once working? If you have, you certainly appreciate the problem and understand the need for versioning source files (discussed in Chapter 18, "Source Code Control"). Also, you need to make sure that you add version information to your applications so that installation programs and adventurous users don't end up overwriting a program with a version that isn't current. Finally, you need to have a solid backup plan to ensure that you never lose important program changes.

Note

The material in this chapter is closely related to the information provided in Chapter 16, "Distributing Solutions." You need to understand the mechanics presented in Chapter 16 to make use of some of the material presented here.