Inside Microsoft® Visual Studio® .NET 2003 [Electronic resources] نسخه متنی

Visual Studio .NET from the Command Line

You can use Visual Studio .NET from the command line to build solutions and projects in much the same way that you might have used NMake.exe to build make files in the past. By using Visual Studio .NET from the command line, you can conveniently build your projects without opening the IDE. The obvious benefit of this approach is that you can automate your build processes through scripting and batch files.

The easiest way to use Visual Studio .NET from the command line is to place the path to Devenv.exe into your PATH environment variable or to do your work from the Visual Studio .NET 2003 Command Prompt window. By default, the PATH, INCLUDE, LIBPATH, and LIB environment variables are the ones set in the IDE, but you can set Visual Studio .NET to use the current variables by specifying the \useenv option on your command line.

Building Projects and Solutions from the Command Line

Building a solution or project from the command line is fairly straightforward, but it's worth reviewing the options you need to specify to do this correctly. To build a solution from the command line, open a command window with Devenv.exe set in the path and navigate to the folder containing the solution file. Then execute the Devenv.exe command on the solution file by using the /build switch followed by the name of the build type you want to run. In most cases, this will be debug or release. If you've created custom build types as described in Chapter 2, you can specify one of these. A typical debug build command for a solution looks something like this:

devenv SCTestVCS1.sln /build debug

Build information is returned to the command window, but you can also send that output to a build log. To do so, specify the /out option with a filename. To review the output of the build process, open the output file in Notepad or run the Type command as shown in Figure 15-1.

To perform a build of a particular project within a solution, use the /project switch. To build a single project that's part of a multiproject solution, your command line might look like the following:

devenv SCTestVCS1.sln /project JSConsoleApp /build debug

In this case, the solution has multiple projects, but only the specified project file is built. If you want to open a solution in the IDE to a particular project configuration, you can specify the configuration using the /projectconfig switch. Opening the IDE in this way lets you get straight into a project and configuration within a particular solution.

You should note a couple of idiosyncrasies when you work with Devenv.exe from the command line. First, you should specify the solution or project file before the other switches in the command. In some cases, you can specify the switches first, but that doesn't work for all switches, so it's easier to just get the solution specification out of the way. Second, you must place any paths with spaces within quotation marks.

The build switches work just like the named commands do in the IDE. The /rebuild switch performs a clean operation on the target folder before the build or forces all the targets to be rebuilt, depending on the language. The /clean switch runs the Build.CleanSolution command on the solution. The behavior of the clean command is dependent on the implementer of the language. It works well for Visual C++ projects, but Visual Studio .NET 2003 doesn't support cleaning the other included project types. As with the build command, you need to specify the build type that you want to clean at the command line:

devenv SCTestVCS1.sln /clean debug /out clean.txt

Here's the output of this command on a solution with multiple project types. (In this case, only one project actually performs the clean command.)

------ Clean started: Project: CPPConsoleNet, 
Configuration: Debug Win32 ------
Deleting intermediate files and output files for project 
'CPPConsoleNet', configuration 'Debug|Win32'.
---------------------- Done ----------------------
Clean: 1 succeeded, 0 failed, 0 skipped

If you want to run the target file that your solution or project creates, use the /run option. This option opens the IDE and runs your program as if you had run the Debug.Start command. If you set a breakpoint that gets hit when your application runs, program execution stops at the breakpoint. This fact can be useful if you find yourself opening and closing the IDE a lot and you want to get straight back to the point where you left off while debugging.

To take a quick look at the output from a particular solution, you can use the /runexit option. This option opens the IDE in a minimized state and runs your executable. The minimized IDE closes automatically when the target process exits. Debugging isn't enabled in the /runexit scenario, so if you have breakpoints set in your code, they're ignored.

The command line for a solution that you want to run within the IDE will look something like this:

devenv VBWinApp.sln /run

If your solution contains a deployment project, you can use the /deploy option to build the solution and run the deployment. This switch has two requirements. First, you must have a deployment project in your solution. Second, you must add your deployment project to the configuration you want to build with. The default for new deployment projects added to projects is to have the project's Build check box cleared. To use the /deploy command, you must open the Configuration Manager dialog box by choosing Configuration Manager from the Build menu. Figure 15-2 shows the dialog box with the appropriate check box selected in the Release configuration for the solution.

To build and deploy a solution like this, close the IDE and enter your command with the /deploy switch, like this:

devenv VBWinApp.sln /deploy release

This should start the deployment program you've created.

One command-line switch you'll find valuable as an add-in developer or macro writer is the /command switch. This switch lets you run a named command as you open the IDE. For example, if you want to open the Code Model Add-in from Chapter 12 when you start the IDE, you simply enter a command line that looks something like this:

devenv /command CMEAddIn.Connect.CMEAddIn

It's not that easy to remember CMEAddIn.Connect.CMEAddin, but one useful feature of this switch is that you can use an alias in place of that named command, making it a lot easier to enter your command. To alias the CME­AddIn line (assuming you have it installed), in the IDE press Ctrl+Alt+A to open the Visual Studio .NET Command Window and then enter the following:

alias cme CMEAddIn.Connect.CMEAddIn

You can then run the add-in from the Windows command line by entering the following:

devenv /command cme

If you have a command that takes arguments, you can place the command within quotes and it will usually be executed correctly. The following command line executes the help alias with the term command as the argument:

devenv /command "help command"

The /command switch works equally well for running macros and aliases to macros. As you can imagine, this gives you access to quite a bit of functionality from the command line. You can use this switch for testing add-ins and macros, for performing operations on solutions, and for setting up batch files that give you access to your own custom IDE setups.

The /debugexe switch opens an executable file in the Visual Studio .NET debugger as a new solution. To run the executable and attach to the process, you can execute the Debug.Start command. At this point, you're prompted to save a new solution and the executable is run in the debugger. You can then break into the source or disassembly for the executable, depending on whether you're debugging a release or debug version of the executable and whether Visual Studio .NET can find the source code for the executable and dependent files. The command line for opening an executable in Visual Studio .NET will look something like the following:

devenv /debugexe VBWinApp.exe

If the last build on this file was a debug build, Visual Studio .NET should have no trouble breaking into the source for the file. If the build was a release build, you can break only into disassembly. The build type is usually a little easier to determine in Visual C# and Visual C++ because the outputs are placed in debug or release folders, depending on the build.

Finally, the /useenv switch is specific to Visual C++. It lets you direct the IDE to use the environment variable set for the command session from which Devenv.exe is run. The setting is helpful if you want to create builds with specific versions of the installed runtime libraries. For example, you might want to use files from a particular version of the Windows SDK or you might want to test beta versions of the DirectX libraries. The /useenv switch lets you do this without having to set these options in the IDE.

Table 15-1 contains a list of the Devenv.exe command-line build options.

Setting GUI Options at the Command Line

The GUI options let you change some of the settings of the IDE from the command line. Some of these might not seem particularly useful at first, but you can use them to test tool windows that you build in your add-ins under different GUI scenarios.

The /mdi and /mditabs switches let you toggle between the use of MDI windows or tabs for document windows in the IDE. Keep in mind that your choice sticks with the IDE, so if you're playing with /mdi and you forget to run Devenv.exe with the /mditabs switch, your tabs will go missing the next time you open the IDE.

There are two font switches, but these affect only the IDE itself and not the document windows. The /fs switch lets you specify the point size for the text displayed in the IDE. The /fn switch lets you specify a particular font name if you want. Again, these settings are sticky, so you should use them with care; you can make the IDE quite unusable if you specify unreasonable values. Figure 15-3 shows the IDE with the /fn switch set to 14.

Finally the /LCID switch lets you run the IDE with a specified language. This switch can be helpful if you're localizing your add-ins. You must have the version of Visual Studio .NET specific to the language you want to use installed on the machine on which you're running the IDE. You can use this option to test your add-ins in different languages without having to set up a bunch of different test machines. MSDN Universal subscribers will have access to these different Visual Studio .NET builds.

Table 15-2 lists the different command-line GUI options.

VSIP Options

The remaining options are used by Microsoft Visual Studio Integration Program (VSIP) partners to test their VSIP solutions. They won't do you much good without access to this program, but we've listed them in Table 15-3 for the sake of completeness.