A.: The key point of incrementing the build version number of your product is to keep the current number somewhere and to get the version number of the previous build during each successive build session. We recommend that you keep the current version number in a file (say, a .txt file in which individual parts of the version number are separated with CRLF characters). If you use this approach, the process of incrementing the build version number can consist of the following steps:

Instead of using a file, you can store your build version number in one or several stored variables, which preserve their current values after the macro run. However, this approach is not as safe because if your macro resets the value of the stored variable somehow, you will lose your version number. To create a stored variable in a macro, select Variables | Stored Variables from AQtime's main menu (select Build Studio | Variables | Stored Variables from the main menu of Visual Studio) and use the resulting Stored Variables dialog. You can set the initial value of the stored variable directly in the dialog. In your macros, you can work with stored variables as with ordinary variables. Make sure that your macro increments the value of that stored variable (that is, the build version number) in an appropriate manner only once - at the end of the macro run. You can do this using the Script or Set Variable operation.

The place where the current build version number is stored within the project you are building depends on the compiler you use.

For instance, in Delphi and C++Builder projects, the version number is part of project options. You can separately set the module version and file version as well as the product version. To set the needed version number in your macro, you can use the Module version number, FileVersion or ProductVersion property that resides on the Version Info property page of the Operation Properties dialog that is called for the corresponding Compile Delphi 3-7 Project, Compile C++Builder 3-4 Project, Compile C++Builder 5 Project or Compile C++Builder 6 Project operation. For instance, if you have the VER_MAJOR, VER_MINOR, VER_RELEASE and VER_BUILD variables that hold the corresponding version number parts, you can set the %VER_MAJOR%, %VER_MINOR%, %VER_RELEASE% and %VER_BUILD% values to the Major version, Minor version, Release and Build properties correspondingly (they are parts of the Module version number property) . See the sample macro <Automated Build Studio>\Samples\Macros\CompileDelphiProject\CompileDelphiProject.bxp. You can also get and set the version-related properties of these operations via script.

Similarly, in Visual Basic 6.0 projects, the version number is part of the project properties. To set the version number in your macro, use the Version Number property on the Make property page of the Operation Properties dialog called for the Compile Visual Basic 6.0 Project operation. This property includes three subproperties used to keep individual parts of the version number (Major, Minor and Revision). You can populate them using the way described above.

In Visual C++ 6.0 projects, as well as in .NET-connected projects, the version number is kept in a resource file that is part of the project. To learn how to generate such a file, see the sample macro <Automated Build Studio>\Samples\Macros\CompileCPPProject\CompileCPPProject.bxp. In short, the technique is as follows. If you have the VER_MAJOR, VER_MINOR, VER_RELEASE and VER_BUILD variables that hold the corresponding version number parts, you can post the #define directives that define constants with the names and values of these variables to a text file. Next, you can concatenate these constants into the integrated version number of the file or of the product. Finally, you can specify an appropriate version number constant in the project's resource file.

A.: Yes, you can. The best way to do this is to use multiple configurations within your macro. A macro configuration includes the following:

Therefore, you can have one structure of operations within your macro for all of the product versions you need to build, and have an individual macro configuration for each of these versions. For instance, one configuration for the Debug version, another configuration for the Release version, etc. To learn more about this, see Using Macro Configurations.

A.: Yes, you can use the Execute Macro operation to do this. The operation runs all of the enabled operations of an existing macro from the beginning. If you wish to run some part of that macro within your current macro, you can specify the configuration that you want to use during the run (if a configuration is defined in that macro). Additionally, the operation lets you set values of variables defined in the macro you are going to run.

A.: Almost all of the operations that belong to the Borland Compilers, Microsoft Compilers or Microsoft Compilers for Smart Devices category have the Output full build log property. If this property is enabled, the entire output generated by the corresponding compiler is posted to the Log panel of Automated Build Studio.

A.:  To get a comprehensive answer to this question, see the Handling Errors in Macros topic in on-line help.

A.: Your macros can automatically notify you of the results of their execution. Automated Build Studio offers several operations that can be used to send notifications. These operations let you send messages via the "net send" command, MSN Messenger, ICQ or e-mail. You can also e-mail reports with attached execution logs. To learn more, see Automatic Notifications.

A.: Macros created with Automated Build Studio Demo can have only 15 operations. The demo version of Automated Build Studio is functional within the 30-day evaluation period.

A.: No. Integration means Automated Build Studio's panels and dialogs become part of Visual Studio's UI. This means you can modify, run and debug your macros directly from within Visual Studio's IDE. However, Automated Build Studio does support visual editing of MSBuild projects, so you can use it for this purpose as well.