I have used Microsoft Visual Studio at various companies over the years, starting with Visual Basic 3 to create simple, stand-alone Windows applications, then later using Visual Basic 5 and 6 for multitiered development. More recently, I've used Visual C++ to create a commercial application, and have recently been doing extensive .NET development using C# for both WinForms and ASP.NET development.

In all of these development environments, I've used the Visual Studio IDE as the primary tool for editing source code, testing, debugging, etc. Back with VB3, it was fairly simple to build the application as well with the IDE, because I was only building single executables (without even the need for an installer). As I progressed into more complex projects using components, then different layers of components, source code control, installers, and databases, my build experience became increasingly tedious, error-prone and frustrating.

About that time I discovered Visual Build, and quickly began automating my build process, starting with checking my code in and out of SourceSafe and compiling my Visual Basic project groups. I saw an immediate increase in consistency and repeatability and a significant decrease in my frustrations (and stress) when building, testing, and releasing updates to the applications I was writing.

The Visual C++ gig was part of larger team that required more coding discipline (and a lot of studying to learn C++), working across a relatively slow VPN link, as I was working remotely. Fortunately, this work environment was already using Visual Build Professional to automate many of their processes, which enabled me to join the development team quickly, as I could use existing build scripts and read them to quickly understand how they operated without constantly bothering fellow coders.

Over the years, the Visual Studio IDE has steadily added new features and (for me) maintained its position as my primary development tool. Visual Studio has consistently provided the ability to build and deploy applications; however, there have always been significant reasons why it wasn't an optimal build solution in my real world. These reasons include the use of third-party tools, source code control, the manual nature of builds using a nonautomated process, and the need to extend a build to do things that weren't necessarily build-related.

Details
The Visual Studio .NET IDE provides a good framework for developing .NET applications and managing the relationships between projects and components as part of a .NET solution. Extensive debugging capabilities are provided, along with Intellisense and other coding assistance, which greatly boosts developer productivity. And it does provide a limited means of automating builds via the devenv.com console application. Visual Build Pro hides the complexity of building Visual Studio projects and solutions by providing a graphical front end for configuring the appropriate command-line flags and adding additional functionality, such as easily building a single, multiple, or all configurations, more control over setting or incrementing versions and assembly properties, etc.

Another advantage of utilizing Visual Build Pro for Visual Studio .NET builds is that you are isolated from changes made between the different versions of Visual Studio. When migrating from Visual Studio 2002 to 2003 to 2005, once the projects have been opened in the IDE and converted to the new format, the build process remains unchanged, since VBP's Make VS.NET action detects and handles each version appropriately, and even takes advantage of MSBuild for Visual Studio 2005 projects and solutions (thereby preventing the need to install Visual Studio itself on the build box).

Employing Visual Build Professional for .NET builds also provides the ability to continue building legacy applications or projects (without a rewrite) as you move forward with the latest technology. The builds you have defined for older languages and tools continue to work and can simply be extended for any new applications you develop (regardless of the manufacturer). In my example, I have continued building some legacy VB 6.0 and VC++ 6.0 applications in addition to the latest .NET projects in development. And Visual Build Pro provides built-in support for all of the major source control systems (SourceSafe, Perforce, Vault, Surround SCM, Subversion, etc.), thus making it easy to incorporate these products into the build process as well.

As much as we like to keep things standard and follow conventions, every shop I've worked at had many exceptional situations that required customization to their build process. This is another major reason to maintain the process using the flexible and powerful build framework provided with Visual Build Professional. Some examples I have encountered are the need to deploy ASP Web sites (first shutting down the IIS server, compiling Delphi components, a legacy method of deploying components to central server, updating metadata in a SQL Server database, etc). I have been very impressed with VBP because I rarely find a build problem that can't be solved using common-sense programming techniques.

Building software is challenging and demanding business, and often requires highly skilled expertise and extensive knowledge. As applications and the tools used to create them have evolved, they have become highly complex and specialized. As mentioned earlier, using Visual Build Professional can greatly reduce the amount of perishable information and research used within the build process. The files used by Visual Build Professional are XML files, which typically are checked in to your source control system just like your application source code, thus preserving the history of your build process. When your core developers leave the company, they don't leave you stranded. Instead the necessary information remains with the company, so the build process isn't compromised.

While the .NET development system is extensive and powerful, it is a very complex tool that spans a wide range of technologies and capabilities. Unless you work for a large company, you probably won't get personal support from Microsoft. It is comforting to have access to the knowledgeable Kinook Software support staff and the Visual Build Professional user base through their support forum. Their level of support is outstanding, the depth of the samples and documentation is second to none, and they have repeatedly demonstrated a willingness to provide assistance when I have been stumped by a particular issue.

Conclusion
I have been a long-time user of Visual Build Professional, and I can honestly say that it has paid for itself many times over. It is the primary tool in my build toolbox that allows me to focus on what I enjoy best: developing and producing software. It is a powerful yet flexible application that achieves what it was designed for: automating any Windows-based software build process. If you either haven't automated your build process or are struggling with your current system, you owe it to yourself and your company to give Visual Build Professional a try!

References

• Visual Build Web site: www.visualbuild.com