Automated Builds in DevStudio, or the Night Build Scenario

Article
07/12/2006

Updated by Ranga Narasimhan
Microsoft Corporation

June 2000

Summary: This article discusses several ways to automate the build process in Developer Studio, including AutoBuild add-ins, VBScript macros, and so forth, allowing the developer to schedule the build to start at a specific time and finish by itself. (12 printed pages)

Introduction

An automated build is a project build in Microsoft® Developer Studio® that can be scheduled to start at a specific time, like late at night, and finish by itself. You can use an automated build for the debug, release, or both configurations of your project(s). In the AutoBld add-in sample provided for automated builds, the build log can be e-mailed to the person of your choice.

**Note **The information here applies to Visual C++® 5.0, Visual J++® 1.1, and Visual C++ 6.0. These tools are also referred to as Developer Studio or DevStudio. The object model and the shell (devenv.exe) for Visual J++ 6.0 are different from the Visual C++ object model and shell (msdev.exe); hence, the information here doesn’t apply to Visual J++ 6.0.

Following are some of the ways to automate the build process:

Use or modify the AutoBuild add-in supplied with MSDN Library for DevStudio.
Create a VBScript macro for DevStudio.
Export a makefile and use NMAKE.
Open DevStudio as an Automation object and remotely handle the build.
Use the Visual C++ 6.0 command-line options for performing the builds.

Use or Modify the AutoBuild Add-in Supplied with MSDN Library for DevStudio

Visual Studio documentation in the MSDN Library includes the AutoBld sample that automates the build process. The AutoBld sample builds a Visual C++ 5.0, Visual C++ 6.0, or Visual J++ 1.1 project. When the build is done, AutoBuild e-mails the specified user with the name of the configuration and the number of warnings or errors. You can find and copy AutoBuild to your local drive by searching the online documentation for "AutoBld" or by looking up the topic AutoBld: Builds One or More Workspaces at Specified Times and Dates.

Optionally, you can generate a build log file (*.PLG file). Any time a build occurs, the .PLG file is overwritten with the latest information. For multiple builds, save or move the .PLG file before starting the next release or debug build. The .PLG file is stored in the project directory that you build.

To set up the AutoBuild add-in, follow these steps

Build and enable AutoBuild in DevStudio.
Use the AutoBuild add-in to specify the project(s) to be built.
Schedule AutoBuild in Microsoft Windows® 95 with Microsoft Plus!, or
Schedule AutoBuild in Windows platforms running Microsoft Internet Explorer 4.0 and later, or
Schedule AutoBuild in Microsoft Windows NT® 4.0 running a version of Internet Explorer earlier than 4.0.

To build and enable the AutoBuild add-in

After copying the add-in, click **Open Workspacefrom the **Filemenu and open the workspace file autobld.dsw.
On the Build menu, click Build AutoBld.dll.
When the build is done, select the Tools menu and click Customize. Click the Add-ins and Macro Files tab.
Click the Browse button and then choose Add-ins (dll) from the File Type as box or open the Debug folder in the AutoBld directory. Select AutoBld.dll and click Open.

**Note **If you do not have administrator privileges on Windows NT 4.0 or Windows 2000, you will not be able to enable the add-in from within DevStudio.

Use the AutoBuild add-in to specify the project(s) to be built

Start DevStudio and disable the Tip of the Day dialog box.
Click the Configure button on the AutoBuild toolbar. Set your preferences in the AutoBuild Configuration dialog box.
Click Workspaces to Build and click Add to add your preferences. These are stored in the system registry.

Scheduling AutoBuild in DevStudio using Windows 95 (Microsoft Plus! required)

Click the System Agent on the Windows 95 taskbar. The System Agent appears next to the clock in the status area on the taskbar. This is only visible if you have Microsoft Plus! installed.
On the Program menu, click Schedule a New Program.
In the Program text box, type:
```
msdev /EX AutoBuild 
```
**Note **The command supplied using the –execute option is case sensitive. DevStudio should be in the path; otherwise, specify full path in the preceding statement.
Set the times and days for AutoBuild to run. Set any other preferences and then click OK.

Scheduling AutoBuild in DevStudio using Windows operating systems running Internet Explorer 4.0 and later

Windows NT 4.0 and Windows 2000 users will have to first start the service if it is not already started. Here is how to do it:
1. On the Windows NT 4.0 taskbar, click Start, point to Settings, open Control Panel,**and double-click Services. It lists all the services along with their status and startup information. Windows 2000 users will have to open Administrative Tools in Control Panel and then launch the Services applet.
2. Find the Task Scheduler service. Windows NT 4.0 users can click the Start button and Windows 2000 users can double-click on the Task Scheduler**service and then select the Start button. If you don’t have administrative privileges, you cannot start or stop the service.
3. By default, the System Account is used by the service to log in. If you run into problems with the account you are specifying on Windows 2000, you should see the Microsoft Knowledge Base article Q223170, Task Scheduler Service Must Be Started with System Account.
  
  **Note **Internet Explorer 4.0 and later installs the Task Scheduler service (uses MSTASK.EXE). If you have problems launching DevStudio using the service on Windows NT 4.0 systems, switch to the Schedule service (uses ATSVC.EXE) that is included with Windows NT 4.0. Refer to the Knowledge Base article Q196731, Application That Requires Schedule Service Fails, for more information. If you use the Schedule service (uses ATSVC.EXE), you will have to then resort to scheduling from the command line. See the next section for details.
  
  Windows 98 users can run msconfig.exe (System Information Utility) and select the Startup tab to view the tasks that are launched during the system startup. See if there is a check mark in the box beside SchedulingAgent; if not, check SchedulingAgent and click OK to start the scheduling agent at system startup.
  
  Windows 95 and Windows 98 users should launch regedit.exe (Registry Editor) and then navigate to
  
  HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\RunServices
  
  to see if there is a string called SchedulingAgent, whose value is set to the path for mstask.exe. If it is there, mstask.exe will be launched during startup.
  
  **Note **Windows 95 users with Internet Explorer 4.0 will have to do a full install of Internet Explorer 4.0 to get this utility.
Follow the steps documented in the Knowledge Base article Q178706, How to Schedule a Program Using Task Scheduler, and select DevStudio (msdev.exe) as the program.
In the previous step, you were unable to add arguments for DevStudio. You will have to go back to Schedule Tasks**window where you will see the new task. Double-click on it and then, in the Run edit box, add “/EX AutoBuild” (without the quotes) as the parameter for msdev.exe. Click OK.

**Note **The command supplied using the –execute option is case sensitive.

Scheduling AutoBuild in DevStudio using Windows NT 4.0 running a version of Internet Explorer earlier than 4.0

On the Windows NT 4.0 taskbar, click Start, point to Settings, open Control Panel**and double-click Services. It lists all the services in a list box along with their status and startup information.
Find the Schedule service, double-click on it and confirm the following:
- Schedule Startup Type**is set to Automatic.
- Log On As is set to System Account.
- Allow Service to Interact with Desktop is checked. If this isn’t checked and if the service is already running, you should first stop the service, check this option, and restart the service. Without this option selected, you will not be able to see DevStudio even though Task Manager lists msdev.exe as a running process.
The “at.exe” utility is used from the command prompt to schedule tasks. The following example runs notepad.exe at 9 AM:
```
at 9:00:00 “c:\winnt\notepad.exe”
```
(To obtain the status on scheduled tasks, type “at” in the command prompt.)

If you use the System Account**for the service, you will not be able to schedule the AutoBuild command using “at” because DevStudio obtains information on registered Add-ins from the following registry key:

HKEY_USERS\.DEFAULT\Software\Microsoft\DevStudio\6.0\AddIns

(For Visual C++ 5.0 and Visual J++ 1.1 the key is HKEY_USERS\.DEFAULT\Software\Microsoft\DevStudio\5.0\AddIns)

If you don’t use the “at” to launch DevStudio, the Add-in information is obtained from:

HKEY_CURRENT_USER\Software\Microsoft\DevStudio\6.0\AddIns

(For Visual C++ 5.0 and Visual J++ 1.1 the key is HKEY_CURRENT_USER\Software\Microsoft\DevStudio\5.0\AddIns)

You should launch DevStudio once using the “at” command, enable the add-in, configure AutoBuild, and quit. This will register add-in information in the appropriate registry key, add the add-in configurations to the registry, and enable you to launch the AutoBuild command.

To schedule a build you will type:

at 9:00:00 “c:\program files\microsoft visual studio\common\msdev98\bin\msdev.exe” /EX AutoBuild

You will have to specify the full path to DevStudio; otherwise, it will not be launched.

**Note **The command supplied using the –execute option is case sensitive.

This will launch the Developer Studio environment and execute the AutoBuild command, which starts the build of your projects.

To get help on the “at” utility, type "at ?" on the command line.

For more information on add-ins in DevStudio, go to Home Page: Add-ins for the Visual C++ Developer Studio in the MSDN Library.

Create a VBScript Macro for DevStudio

A Microsoft Visual Basic®, Scripting Edition (VBScript) macro provides another method of performing a scheduled build. There are two ways to create a VBScript macro: record one in the DevStudio environment or type one in a macro file (a .DSM file). VBScript macro files can contain more than one macro. The sample VBScript macro included here, DoAllFire, builds all projects in the workspace in all the configurations. You can easily modify the DoAllFire macro to contain your own projects and workspaces and build everything, or just the configurations and files you wish.

For information on differences between add-ins and VBScript macros, see Differences Between VBScript Macros and Developer Studio Add-ins in the MSDN Library.

To copy and install the DoAllFire macro file, Buildsam.dsm

In DevStudio, select New from the **File****menu, select the Files tab, select Macro File, give the file a name (Buildsam.dsm), and click OK. This will create a new macro file. Copy the VBScript macro code below to this file and save the file:

Sub DoAllFire

Dim projCol
Dim configCol
Dim numProjects
Dim numConfigs
Dim i
Dim j

‘Obtain the Projects collection
set projCol = Projects
‘Obtain the number of projects in the workspace
numProjects = projCol.Count
   ‘Iterate through all the projects in the workspace
   For i=1 To numProjects
      Dim proj
      ‘Obtain the Project object
      set proj = projCol(i)
      ‘See if the project is buildable
      If proj.Type = "Build" Then
         ‘Obtain the Configurations collection for the Project object
         set configCol = proj.Configurations
      ‘Obtain the number of configurations
         numConfigs = configCol.Count
      ‘Iterate through all the configurations of the Project object
         For j=1 to numConfigs
            Dim config
        ‘Obtain the Configuration object
            set config = configCol(j)
         ‘Build the Configuration
            Build config
         Next
      End If
   Next
End Sub

On the Tools menu in DevStudio, click Customize.
Click the **Add-ins and Macro Filestab. The file Buildsam.dsm should appear in the window. If the file does not appear, click the **Browsebutton to locate the file.
Load Buildsam.dsm by selecting the checkbox next to its name. This check mark also directs the development environment to load the file automatically when you start the environment again.

**Warning **If you remove the check mark next to a macro file name, you unload it. When you unload it, all of the macros in the file lose their toolbar and keystroke assignments.

To edit a VBScript macro

On the Tools menu, click Macro.
In the Macro File window, select Buildsam.dsm, which contains the macro you wish to edit. If Buildsam.dsm is not in the list, first install the file (see previous section entitled To copy and install the DoAllFire macro file, Buildsam.dsm), then select it in the Macro File window.
In the Macro File**window, select the VBScript macro, DoAllFire, that you wish to edit.
Click the Edit button.
Make the appropriate changes.
Right-click the mouse on the .dsm file in the DevStudio editor and select Reload Macro File. This will save the macro and reload it.

Running the VBScript Macro, DoAllFire

Running a VBScript macro is similar to running add-in commands. You can run macros from toolbar buttons or key sequences assigned to the macros, from the **Macros****dialog box, or from the command line. For more information on the first two methods, see Running VBScript Macros in the MSDN Library.

To run a macro from the command line

Disable the **Tip of the Day****dialog box in DevStudio.
At the command line, type:
```
msdev MyProject.dsw /EX DoAllFire
```
**Note **The command supplied using the –execute option is case sensitive. DevStudio should be in the path; otherwise, specify full path in the preceding statement.

DoAllFire is the name of the macro. This syntax starts the Developer Studio environment, opens the workspace, and runs the macro.

If you want DevStudio to shut down after the build is complete, edit the macro so that it calls the Quit method of the Application object.

Scheduling the DoAllFire macro on Windows platforms

The steps for scheduling the DoAllFire macro and the AutoBuild add-in are similar, with some minor changes. Instead of using AutoBuild command, use DoAllFire and specify the workspace to build. Also, if you are scheduling it on a Windows NT 4.0 system that has an Internet Explorer version earlier than 4.0, the registry keys accessed are different. In that case, DevStudio obtains information for macros from the following registry key when the System Account is used with “at”:

HKEY_USERS\.DEFAULT\Software\Microsoft\DevStudio\6.0\Macros

(For Visual C++ 5.0 and Visual J++ 1.1 the key is HKEY_USERS\.DEFAULT\Software\Microsoft\DevStudio\5.0\Macros)

Otherwise, the following registry key is used:

HKEY_CURRENT_USER\Software\Microsoft\DevStudio\6.0\Macros

(For Visual C++ 5.0 and Visual J++ 1.1 the key is HKEY_CURRENT_USER\Software\Microsoft\DevStudio\5.0\Macros)

For information on debugging VBScript macros see Debugging VBScript Macros in the MSDN Library.

Export a Makefile and use NMAKE

DevStudio provides some built-in commands for automation. To see a list of these commands, select Customize under the Tools menu and choose the Keyboard tab. The commands under the respective categories are listed. These commands can be launched in the same way that add-ins and macro commands are launched. To export a makefile for all the projects in a workspace, do the following from the command line:

msdev.exe MyProject.dsw –execute BuildProjectExport

**Note **The command supplied using the –execute option is case sensitive. DevStudio should be in the path; otherwise, specify full path in the preceding statement.

The above will launch DevStudio, open the MyProject.dsw workspace file, and then export makefile for all the projects. There is a drawback in doing this—you will see the Export Makefile dialog box. The same can also be accomplished using the following VBScript macro:

Sub ExportMakFile
   'Export the makefile
   ExecuteCommand "BuildProjectExport"
   'Close the workspace
   ExecuteCommand "WorkspaceClose"
   'Exit from DevStudio
   Quit
End Sub

This will give you greater flexibility, works great, and lets you quit from DevStudio. (There is a bug in Visual C++ 5.0 that launches a dialog box when the above macro is used with a workspace with more than one project.)

After the makefile is exported, use the nmake tool shipped with DevStudio to perform a build of the project(s) in the workspace. See Overview: NMAKE Reference in the MSDN Library for information on the nmake tool.

You can place the command to export a makefile and the command to build using nmake in a batch file, and then schedule the processing of the batch file. Scheduling a batch file will be similar to scheduling macros and add-ins. The previous sections have information on scheduling tasks (instead of specifying msdev.exe, you should specify the batch file name and the project name as the parameter) on the various Windows platforms. A sample batch file could look like:

REM Build.bat is the file name
REM Pass the project name as the parameter, the project name is case 
REM sensitive.
REM DevStudio should be in the path otherwise specify full path in the next 
REM statement.
msdev.exe %1.dsw /EX ExportMakFile
if not exist %1.mak goto errorinfo
nmake /nologo -f %1.mak CFG="%1 - Win32 Debug"
echo "Build succeeded."
goto :EOF
errorinfo:
echo "The makefile wasn't exported successfully."

Open DevStudio As an Automation Object and Remotely Handle the Build

DevStudio is an Automation server that can be programmed using COM-aware clients such as Visual C++, Visual Basic, Visual J++, and so on. You can control launching DevStudio, opening a workspace, performing a build, and so forth, by using a client application. The Knowledge Base article Q247035, HOWTO: Automate Visual C++, documents sample code that launches DevStudio, opens a workspace specified on the command line, and builds the project(s) in the workspace in all the configurations. This sample is similar to the DoAllFire macro mentioned in the Create a VBScript macro for DevStudio section of this article.

To launch DevStudio on a remote machine, you will have to modify the sample code by using CoCreateInstanceEx instead of CoCreateInstance, or you can use DCOMCNFG.EXE. To modify the launch and access permissions on the server, use DCOMCNFG.EXE. Here is the code snippet if you want to use CoCreateInstanceEx in the sample mentioned in the Knowledge Base article Q247035, HOWTO: Automate Visual C++:

MULTI_QI mqi = {&IID_IApplication, NULL, S_OK};
COSERVERINFO serverinfo = {0, L"ranga1", 0, 0};
//Assuming default security
hr = CoCreateInstanceEx(CLSID_Application, NULL, CLSCTX_REMOTE_SERVER, &serverinfo, 1, &mqi);

if(FAILED(hr))
{
   printf("Failed to create an instance of MSDEV\n");
      CoUninitialize();
   return FALSE;
}

pApp=static_cast<IApplication*>(mqi.pItf);

To the above code, add a #define _WIN32_DCOM at the beginning of the source code (before the #includes) to enable DCOM preprocessor support.

For more information on DCOM, see the articles DCOM Architecture and Security in COM in the MSDN Library. If you wish to write code in Visual Basic 6.0, CreateObject method can be used to launch DevStudio on a remote machine and most of the code will be similar to the DoAllFire macro.

DCOM for Windows 95 and Windows 98 can be downloaded from https://www.microsoft.com/com/resources/downloads.asp.

If you prefer, you can use the Windows Script Host (WSH) as the client to automate DevStudio. The previous sections contain documentation on scheduling tasks (instead of specifying msdev.exe, you should specify the client application file name with the necessary arguments) on the various Windows platforms.

Discussion on COM and DCOM are beyond the scope of this article.

Use the Visual C++ 6.0 Command-Line Options for Performing the Builds

Visual C++ 6.0 provides command-line options for building projects in a workspace. To get a list of all the command-line options for Visual C++ 6.0, see the article Building a Project from the Command Line in the MSDN Library. The following syntax builds a workspace that contains (at least) two projects, building the release configuration of MyProject1 and all configurations of MyProject2, and directing the build output to a file called MyWorkspace.log:

msdev MyWorkspace.dsw /MAKE "MyProject1 – Win32 Release" "MyProject2 – ALL" /OUT MyWorkspace.log

**Note **DevStudio should be in the path; otherwise, specify full path in the preceding statement.

When you use the preceding command, DevStudio will not be visible. This is by design. The previous sections of this article contain documentation on scheduling tasks on the various Windows platforms. (That is, pass the workspace name and the project(s) to be built as arguments for msdev.exe.)

Tips

Launch DevStudio at least once after installation before attempting to automate it. The setup program doesn’t create the HKEY_CURRENT_USER\Software\Microsoft\DevStudio key. It's created only when you launch DevStudio the first time.
You may want to manually open the workspace that you are building once and close it to see if a dialog box appears.
If you are porting projects between different versions of DevStudio, open the projects at least once to see if a dialog box appears. For example, if you open a Visual C++ 6.0 project in Visual C++ 5.0, you will be asked whether you want to overwrite the NCB file.
You may run into problems if you are building over a network. See the Knowledge Base article Q130615, PRB: Unwanted Rebuilds Occur When Using NMAKE or Visual C++, for more information.
If you chose not to run vcvars32.bat file during the DevStudio setup, you should run this file in the command prompt to run any of the DevStudio tools from the command prompt. See the Knowledge Base article Q248802, PRB: Vcvars32.bat Generates Out of Environment Message, for more information.
If you wish to increment version number of the application being built using DevStudio after each build, see the Knowledge Base article Q237870, HOWTO: Increment Version Information After Each Build in Visual C++.
The option for generating the BSC (source browser) file from the SBR files using the bscmake.exe tool is stored in the OPT file. Generating the BSC file is a per user setting. If you are using a source code control system where the OPT file is not checked in, you know the reason why the BSC file is not created when someone else checks it out and does a build. See the Knowledge Base article Q156513, INFO: Which Visual C++ Files to Add to Source-Code Control, for more information.
If you are experiencing crashes in DevStudio when scheduling it to run using the “at” command on Windows NT 4.0 and Windows 2000, the Knowledge Base article Q165194, INFO: CreateProcessAsUser() Windowstations and Desktops, may apply.

Reference

Extending Developer Studio with Add-ins by Richard Grimes (May 1998 issue of Visual C++ Developer)

Extend Developer Studio 97 With Your Own Add-ins, Macros, and Wizards by Steve Zimmerman

Enhancing the Visual C++ 5.0 Workplace with VBScript Macros by Mark Davis (October 1997 issue of Visual C++ Developer)