|Important||This document may not represent best practices for current development, links to downloads and other resources may no longer be valid. Current recommended version can be found here. ArchiveDisclaimer|
Building and Debugging (Visual C#)
In Visual C#, you build an executable application by clicking Build on the Build menu (or pressing CTRL+SHIFT+B). You can build and start the application in one operation by pressing F5 or clicking Run on the Debug menu.
Building involves inputting your project files into the C# compiler, which converts your source code into Microsoft intermediate language (MSIL) and then joins the MSIL with the metadata, resources, manifest and other modules, if there are any, to create an assembly. An assembly is an executable file that typically has an extension of .exe or .dll. As you develop your application, you will sometimes want to build a debug version of it in order to test it and see how it runs. Finally, when everything is correct, you will create a release version that you will deploy to customers.
For more information about assemblies, see.
To specify various build settings, right-click the project item in Solution Explorer and then select the Build pane in the Project Designer. For more information, seeand .
Visual Studio uses the MSBuild tool to create assemblies. MSBuild can also be run from the command line and can be customized in many ways. For more information, see.
If there are any errors in your C# syntax, or identifiers that cannot be resolved into a known type or member, then your build will not succeed and you will see a list of errors in the, which appears by default directly below the code editor. You can double-click on an error message to go to the line in your code where the error occurred.
C# compiler error messages are generally quite clear and descriptive, but if you cannot figure out the problem, you can go to the Help page for that message by pressing F1 with the error message selected in the error list. The Help page contains additional useful information. If you still cannot solve the problem, then the next step is to ask your question on one of the C# forums or newsgroups. To access the forums, click Ask A Question on the Community menu.
If you encounter a compiler error Help page that was not helpful for your particular error, you can help Microsoft improve the documentation by sending a description of the problem. To send the e-mail, click the link at the bottom of the Help page that contains the error.
Release vs. Debug configurations
While you are still actively working on your project, you will typically build your application using the debug configuration, because this configuration enables you to view the value of variables and control execution in the debugger. You can also create and test builds in the release configuration to ensure that you have not introduced any bugs that only manifest on one type of build or the other. In .NET Framework programming, such bugs are very rare, but they can happen.
When you are ready to distribute your application to end users, create a release build, which will be much smaller in size and will usually have much better performance than the corresponding debug configuration. You can set the build configuration in the Build pane of the Project Designer, or in the Build toolbar. For more information, see.
At any time you are working in the code editor, you can set a breakpoint on a line of code by pressing F9. When you press F5 to run your application within the Visual Studio debugger, the application will stop on that line and you can examine the value of any given variable, or observe how or when execution breaks out of a loop, step through the code one line at a time by pressing F10, or set additional breakpoints.
You can also set conditional breakpoints, which will only stop execution if a specified condition is met. Tracepoints are similar to breakpoints except that they do not stop execution, but simply write the value of a specified variable to the output window. For more information, see.
When execution is stopped on a breakpoint, you can hover over any variable in scope to view information about that variable. The following illustration shows a data tip in the debugger:
You can step through your code one line at a time by pressing F10 after the debugger has stopped on a breakpoint. You can even fix certain kinds of errors in your code, and continue debugging without having to stop and recompile your application.
The Visual Studio debugger is a powerful tool and it is worthwhile to take the time to read the documentation in order to understand different concepts such as, , , and .