Mastering Visual Studio .NET

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The first product Microsoft ever built was a Basic interpreter for the Altair 8800 personal computer, so they've had a lot of years to perfect their development tools. That time has not been wasted. Visual Studio .NET is the culmination of more than a decade of work on Visual C++, Visual Basic, Visual InterDev, and Visual J++. In this chapter, we will introduce the foundation of all VS.NET-based software development: solutions and projects. Everything that you do with VS.NET will revolve around these two concepts, so a sound understanding of these is central to making effective use of this tool.

To build anything with Visual Studio .NET, you need to use a solution, and that solution must contain at least one project. Solutions are the containers for all your work in VS.NET. A solution contains a project for each build output. (For example, if you want to build a DLL, an EXE, and an MSI Installer file, your solution will contain three projects.) Projects themselves contain source files. In this chapter, you will learn the ins and outs of solutions and projects and how to use them as effectively as possible.

A solution contains a collection of projects, along with information on dependencies between those projects. The projects themselves contain files. This structure is illustrated in Figure 1-1. You can have as many projects as you like in a solution, but there can be only one solution open at a time in a particular instance of VS.NET. (You can, of course, open multiple solutions by running multiple instances of VS.NET.)

Figure 1-1: A solution, its projects, and their files

Solutions contain only projects—you cannot nest one solution inside another. However, projects can belong to multiple solutions, as Figure 1-2 shows, which gives you great flexibility for organizing your builds, particularly in large applications.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

A solution contains a collection of projects, along with information on dependencies between those projects. The projects themselves contain files. This structure is illustrated in Figure 1-1. You can have as many projects as you like in a solution, but there can be only one solution open at a time in a particular instance of VS.NET. (You can, of course, open multiple solutions by running multiple instances of VS.NET.)

Figure 1-1: A solution, its projects, and their files

Solutions contain only projects—you cannot nest one solution inside another. However, projects can belong to multiple solutions, as Figure 1-2 shows, which gives you great flexibility for organizing your builds, particularly in large applications.

Figure 1-2: Projects that belong to multiple solutions

With Microsoft's previous generation of development tools, each language had its own integrated development environment. Now there is just one unified environment. In addition, there are no restrictions on the range of different project types any single solution can contain, so you can work on, say, an unmanaged C++ DLL in the same solution as a VB.NET Window Forms application, which can greatly simplify development, debugging, and deployment. But before we get too excited about that, let us see how to create a solution.

A new solution may be created in many ways in VS.NET. The simplest is to create a new project—by default, Visual Studio .NET will create a new solution with the same name as the project, placing the solution files in the same directory as the project. Although this works fine for small projects, it isn't well suited to more complex applications. Since a solution is a container of projects, it does not make sense for the solution file to be inside the project directory. For multiproject solutions, having the directory structure reflect the solution structure usually makes more sense—it is best to have a directory that contains your solution file, with subdirectories for each individual project.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

A project has two main jobs: to act as a container for our source files and to compile those files into some kind of component, typically either a Dynamic Link Library (DLL) or Windows Executable (EXE). We shall now run through the main types of projects supported by VS.NET.

Visual Studio .NET classifies projects by implementation language and then by project type in its New Project dialog box. However, many of the project types have a great deal in common despite using different languages, so although VS.NET 2003 Enterprise Edition lists more than 90 distinct types, most fall into one of six groups: managed local projects, managed web projects, Smart Device projects, unmanaged local projects, unmanaged web projects, and setup projects.

Your copy of Visual Studio .NET may have even more project types—third-party add-ins can extend the list. You can also add your own project templates—see Chapter 9.

A managed local project will create a .NET assembly. Managed web projects do the same, but the project output is intended to be accessed by a client over a network connection, typically using either a browser or a web service proxy. Web projects are therefore always associated with a web application on a web server. And although managed web projects produce a .NET assembly just like a managed local project, with a web project, Visual Studio .NET will place the assembly on the web server as part of the build process.

A web project can reside on either a remote web server or the web server on your local machine. Visual Studio .NET does not make any distinction between these two styles of development. However, if you use a remote server, you may need to modify its security settings in order to debug a web application successfully. See Chapter 3 for more information on debugging web applications.

Smart Device projects are available only in C# and VB.NET, and they build applications that target Pocket PCs and other mobile devices. These projects are not available with VS.NET 2002.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Remember that solutions do not just contain projects—they also hold information on the relationships between those projects. So once you have the projects you require in your solution, you must make sure Visual Studio .NET knows about the dependencies between them so that the projects will be built correctly. With .NET projects, this is done by setting up references from one project to another.

All projects have a list of references, which is shown in the Solution Explorer directly beneath the project node. (See Figure 1-12.) Each item in this list represents a reference to some external component that your project uses.

Figure 1-12: References

These external components can be .NET assemblies, COM components, or other projects within the same solution. With a .NET project, unless you add an external component to the References list, you will not be able to use that component's types in your project.

With unmanaged C++ projects, you will add references only to other projects—you will not use the .NET or COM reference types. If your project depends on external C or C++ components, you will use the traditional ways of importing type definitions. (#include the header files and link in the .lib files.) For COM components, either #include the appropriate header files or use the #import directive on the relevant type library.

Adding a reference can serve up to four purposes:

With .NET projects, it causes Visual Studio .NET to tell the compiler that your code uses the component, enabling you to use the types it contains—if you don't have the appropriate references in your project, you will get compiler errors complaining that a type or namespace cannot be found.
If the component referred to is another project, Visual Studio .NET will infer dependency information from this and will use this information to work out the right order in which to build projects. (For example, if Project A has a reference to Project B, VS.NET will build Project B first, because it knows that Project A depends upon it.)

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Several different strategies are available when choosing a logical structure for your projects and solutions. So far, we have just used a single solution containing all of the projects that we are working on. (We also saw how to make sure that the physical structure of the solution on the filesystem matches the logical structure.) But there are other options, and thinking about the structure of solution(s) and projects before you start to write code will potentially save you time in the end.

Remember that a project may belong to more than one solution. This gives us some flexibility in the way that we structure our projects. We will now examine the three basic ways to organize your solution(s) and projects and discuss their pros and cons.

The easiest way to organize your projects is to put them all in a single solution—the approach we have used so far in this chapter. The main advantage of this style is its simplicity. This structure also makes automated builds simple, since only one solution will have to be built. The disadvantage is the lack of flexibility in a large project—any developers who wish to work on the solution will always have to have all of the solution's projects downloaded from the source control database.

Problems can arise as the number of projects in the system grows. Although VS.NET has no hard limit to the number of projects that can be added to a solution, at some point a solution with a large number of projects will become unwieldy. It can take a long time to open, since VS.NET will check the status of every project in the source control database. Large solutions will cause more memory to be consumed. Big solutions may also present logistical problems if multiple developers need to make changes to the solution files. Another potential problem is that as the solution gets bigger, the build time will tend to be unnecessarily high, as VS.NET may decide to rebuild files that a developer may not even be working on right now (although you can, of course, mitigate this by creating configurations that build only subsets of the solution). The next technique provides a solution to most of these problems.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Projects and solutions are at the core of any work you do with Visual Studio .NET. Projects represent individual components or applications. Solutions are collections of related projects. Solutions can manage the dependencies between projects, ensuring that components are built in the correct order and copied into the right places. Of course, a solution and its projects would be of no use at all if they didn't contain source code of some kind, so in the next chapter we will look at the features in Visual Studio .NET designed to help you edit individual files.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

In the last chapter, we examined solutions and projects in great detail without ever seeing any source code. However, the vast majority of the time you spend with Visual Studio .NET will involve writing code rather than configuring your solutions and projects. So we will now look at the features Visual Studio .NET offers to improve your productivity when editing files.

Visual Studio .NET provides a text editor that provides the basic source code editing facilities that are common to all languages. Each language service can extend the text editor to provide language-specific features. (See Chapter 10 for information about how language services extend VS.NET.) As well as supplying the basic text editing services, the editor also has hooks that allow language services to provide advanced features, such as IntelliSense and automatic formatting. Even though the exact way in which these services work is language-specific, the IDE provides the basic framework so that the behavior is as consistent as possible across languages.

You can configure the way the text editor behaves for each language. When a particular language takes advantage of a standard editor feature such as IntelliSense, you will be able to configure that feature's behavior either globally or, if you prefer, on a per-language basis. Most languages also have their own unique configuration options. You can edit all of these options by selecting Tools → Options and then selecting the Text Editor folder in the lefthand pane of the Options dialog box. As Figure 2-1 shows, you will see a list of supported languages. Appendix D describes all of the available options.

Figure 2-1: The Text Editor Options dialog box

Visual Studio .NET provides many coding aids to make editing your source code easier. The following sections describe each of these features.

Visual Studio .NET provides a number of context-sensitive autocompletion features, collectively referred to as IntelliSense. VS.NET relies on the language service for the file you are editing to work out which symbols are in scope and uses this to show pop-up lists of suggestions, to show information in ToolTips or to autocomplete your text.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Visual Studio .NET provides a text editor that provides the basic source code editing facilities that are common to all languages. Each language service can extend the text editor to provide language-specific features. (See Chapter 10 for information about how language services extend VS.NET.) As well as supplying the basic text editing services, the editor also has hooks that allow language services to provide advanced features, such as IntelliSense and automatic formatting. Even though the exact way in which these services work is language-specific, the IDE provides the basic framework so that the behavior is as consistent as possible across languages.

You can configure the way the text editor behaves for each language. When a particular language takes advantage of a standard editor feature such as IntelliSense, you will be able to configure that feature's behavior either globally or, if you prefer, on a per-language basis. Most languages also have their own unique configuration options. You can edit all of these options by selecting Tools → Options and then selecting the Text Editor folder in the lefthand pane of the Options dialog box. As Figure 2-1 shows, you will see a list of supported languages. Appendix D describes all of the available options.

Figure 2-1: The Text Editor Options dialog box

Visual Studio .NET provides many coding aids to make editing your source code easier. The following sections describe each of these features.

Visual Studio .NET provides a number of context-sensitive autocompletion features, collectively referred to as IntelliSense. VS.NET relies on the language service for the file you are editing to work out which symbols are in scope and uses this to show pop-up lists of suggestions, to show information in ToolTips or to autocomplete your text.

Four varieties of assistance are offered by IntelliSense. All of them can be invoked manually from the Edit

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The HTML/XML language service provides IntelliSense. For embedded client-side script in HTML, this works in much the same way as it does for any other programming language. And although the tags in HTML and XML documents do not constitute a programming language as such, VS.NET will still provide IntelliSense for tag and attribute names when it can.

The HTML navigation bar has two buttons on the right side. If you press the leftmost button, you can get a script-only view of your HTML—all of the HTML display elements will be hidden, leaving just the client-side script, as Figure 2-6 shows. If you select the rightmost button, nothing will be hidden.

Figure 2-6: HTML script-only editor view

The HTML editor can present two views of your page. It can present a raw text view, or it can show the page as it will appear in the browser. You can select the view you want by clicking on the HTML or Design button—they appear at the bottom left of the editor. (Or you can use Ctrl-PageUp or Ctrl-PageDown.) Even though the design view shows the page as it will appear in a browser, you can still use it to edit any text on the page—it provides WYSIWYG text editing.

If you select View → Properties Window (F4) while in the XML or HTML editor, you will get a special property window that is different from the one you will see if you select the file in the Solution Explorer. The properties are different for HTML and XML files, but they do have one property in common: targetSchema. Visual Studio .NET uses this property to work out how to validate the document. It also uses it to determine which elements to display in IntelliSense member lists.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The CSS Editor uses the normal text editor, but it also supplies a second, nontextual view. Whenever you are editing a CSS file, an extra tool window called CSS Outline will be available, presenting a tree view of the CSS file, as Figure 2-9 shows. By default, this view will be docked to the left of the screen, but since it is a tool window, you can dock it anywhere or undock it completely.

Figure 2-9: CSS Outline

There is also a visual code generator for CSS. When you select a CSS style in the text view, you can select Build Style... from the main Style menu or from the context menu. This will display a dialog that lets you edit the style visually. You can also select Styles → Style Rule to add a new style rule. You can preview your stylesheet by selecting View in Browser from the context menu. By default, this will show a test page that contains text with a variety of styles, but you can choose your own preview page by going to Styles → Select Preview Page.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Certain types of .NET source file represent a user interface of some sort. The two most common examples are a C# file containing a Windows Forms Form class and an ASP.NET .aspx file. Of course, Visual Studio .NET will let you edit these files as text, but it is also able to provide a design view. A design view displays how the user interface will look at runtime (or a reasonable approximation of it) and allows it to be edited visually using drag and drop.

Design views are provided by software components called designers. It is possible to write your own custom designers. (This is most commonly done for Windows Forms controls, as described in Chapter 7.) However, the system provides a number of built-in designers. Designers are provided for Windows Forms and ASP.NET source files, but they are also available for certain types of file that are not intended for display. (For example, you can open a design view for any class that derives from System.ComponentModel.Component.)

You can switch back and forth between the design view and the source view with keyboard shortcuts. If the source code view is visible, F7 will show the design view. If the design view is visible, Shift-F7 will show the source code view. You can also choose the view from the Solution Explorer—by default, it will show the design view when you double-click on a file, but the context menu allows you to choose the code view instead.

But before we can look at the design views themselves, we need to look at a closely related VS.NET feature, the Toolbox.

The Toolbox itself is not a designer, but it is a crucial part of the VS.NET design-time architecture. The Toolbox (View → Toolbox or Ctrl-Alt-X) is a tabbed control that appears to the left of the text editor window by default. It contains items that can be dragged onto a design view. Depending on the file and view you are editing, the selection of tabs available in the Toolbox can change. (This is coordinated by the language service.) For example, if you are editing a Windows Forms source file, the Toolbox will show a list of controls, as Figure 2-10 shows.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

In addition to the text editor and the specialized designers, a number of other editors are built into VS.NET. Editors are supplied for bitmaps, Win32 resource files, string resources, dialog resources, and version resources. VS.NET can also edit any binary file, as it supplies a hex/ASCII dump editor.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

When you open a file, Visual Studio .NET chooses which editor to use based on the file's extension. However, it is sometimes useful to edit that file with a different editor. For example, when you open an .asmx file, the default editor will let you edit only either the design view or the associated codebehind file. It will never show you the contents of the .asmx file itself. If you want to edit the .asmx file directly, you need to open it with the text editor. You can open any file in a project with the editor of your choice by selecting it in the Solution Explorer and then selecting View → Open With.... (You can also select Open With... from the file's context menu in the Solution Explorer.) This will display the dialog box shown in Figure 2-11.

Figure 2-11: The Open With dialog box

From this dialog you can edit the file with any editor in the listbox. The editor with the (Default) tag after it is the default editor for the chosen document. You can change the default editor by selecting one from the list and clicking on the Set as Default button on the dialog box.

You can also use this dialog to add additional programs to the list of editors. Pressing the Add button displays a dialog box in which you can enter the path and name of an application. When you select that editor, VS.NET will spawn that application and pass the currently selected document to it.

The Visual Studio .NET text editor supports multiple character sets. Visual Studio .NET usually guesses which encoding should be used when opening files, but the Open With dialog box allows you to override its decision. As Figure 2-11 shows, some of the entries in the Open With list have the text "With Encoding" after them. If you select any of these, the Encoding dialog box (see Figure 2-12), which allows you select a specific encoding, will appear.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

In C#, J#, and VB.NET projects, all source files have a Custom Tool property. This can be used to process a file at design time, optionally generating another file to be compiled into the project. The most common application of this in VS.NET projects is to generate a type-safe wrapper for the DataSet class from an XML schema file (.xsd). (See Chapter 5 for more information on type-safe DataSet wrappers.) However, this system is extensible, allowing you to add your own custom tools to generate code.

A custom tool is a COM component that VS.NET will run every time the source file changes and is saved. It must implement the IVsSingleFileGenerator COM interface. The main interesting method on this interface is Generate. VS.NET will call this each time the source file is saved, passing in the filename and the contents of the input file. The Generate method returns an array of bytes that will contain either C#, J#, or Visual Basic .NET source code, depending on the type of project. VS.NET saves these bytes to a file, which it compiles when the project is next built. (You can see this file in the Solution Explorer by pressing the Show All Files button.) Because the generated file is compiled as part of the project, IntelliSense will be available during development time for all of the types it defines.

While you could implement the IVsSingleFileGenerator COM interface directly, a managed base class provided in Visual Studio .NET 2002—Microsoft.VSDesigner.CodeGenerator.BaseCodeGeneratorWithSite—is much easier to use. To use it, just import the Microsoft.VSDesigner.dll assembly in the Common7\IDE directory of the VS.NET program directory. Your class must be decorated with the Guid attribute to determine its CLSID, but apart from that, the only thing you have to do is write the Generate method itself. The following code shows the implementation of a simple code generator.

[Guid("A0B5E5E9-3DF8-48bc-A6BA-E0DFD35C6237")]
public class MyGenerator : BaseCodeGeneratorWithSite
{
    public override byte[  ] GenerateCode(string file, string contents)
    {
        string code = "public class Foo { }";
        return System.Text.Encoding.ASCII.GetBytes(code);
    }
}

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Visual Studio .NET provides basic text editing facilities that are shared by all of the languages in the IDE. It can also provide advanced facilities, such as IntelliSense and automatic formatting when appropriate. Certain specific file types also have their own editors, such as the WYSIWYG HTML editor. Furthermore, certain types of source files can be viewed through the editor or through a design view, such as the Windows Forms designer.

So now that we have looked at all of the facilities required to write code—solutions, projects, and file editors—the next step will be to find the inevitable bugs in our code. So in the next chapter we will focus on the debugging features of Visual Studio .NET.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Faulty code has been with us since the dawn of computing. The first general-purpose stored-program computer to become fully operational was the EDSAC, built at England's University of Cambridge. Maurice Wilkes was in charge of this project and recalls that while writing the computer's first real application, "the realization came over me with full force that a good part of the remainder of my life was going to be spent in finding errors in my own programs." If his 126-line program running within the confines of the EDSAC's 2-kilobyte memory capacity proved so difficult to debug, then what hope can there be for modern computer systems, which are many orders of magnitude more complex? Fortunately, debugging technology has improved since the 1940s.

Visual Studio .NET moves the state of the art of debugging forward. As you would expect, it provides all of the features we now consider mandatory in a debugging tool—source-level debugging, single-stepping, breakpoints, and variable watches. It also has many new and powerful features. Multiprocess and multihost applications can now be debugged from a single session. Multilanguage projects are supported. A single debugging session can deal seamlessly with code written in radically different technologies such as managed code, native code, and T-SQL. Web applications can now be debugged with ease.

Debugging is notoriously susceptible to the observer's paradox: you cannot examine anything without changing it. Ideally, the act of attaching a debugger would not change a program's behavior at all. In practice, most developers are familiar with the phenomenon in which faulty programs stop misbehaving the moment the debugger is attached. The two main reasons for this are:

Compilers need to generate slightly different (and less efficient) code than normal in order to allow debuggers to work, which can cause subtle changes in program behavior.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Debugging is notoriously susceptible to the observer's paradox: you cannot examine anything without changing it. Ideally, the act of attaching a debugger would not change a program's behavior at all. In practice, most developers are familiar with the phenomenon in which faulty programs stop misbehaving the moment the debugger is attached. The two main reasons for this are:

Compilers need to generate slightly different (and less efficient) code than normal in order to allow debuggers to work, which can cause subtle changes in program behavior.
Attaching a debugger often changes the speed of execution (radically so if you single-step a thread or halt it with a breakpoint). Software systems are usually highly dynamic entities, so changing the speed at which they run often changes the observable behavior.

Visual Studio .NET is able to debug release builds, albeit with reduced functionality, which can avoid the first problem. However, with .NET applications, attaching the debugger can change the JIT compiler's behavior, so in some cases there are no simple solutions to these problems. (Running debug builds in your production systems can sometimes remove the symptoms of such a problem, but it is hardly a solution. At best, it is an emergency stopgap.) Visual Studio .NET attempts to tread lightly in debugging sessions, but inevitably you will come across the occasional heisenbug—a bug that vanishes as soon as you try to look at it (with apologies to Werner Heisenberg and his Uncertainty Principle). At this point, you must abandon the debugger and resort to the time-honored techniques that have served us well since the 1940s: painstaking detective work, deep thought, trial and error, printf (or its spiritual successors such as Debug.WriteLine), and copious supplies of caffeine.

The debugger's job is to allow us to examine a running program's behavior so that we can pinpoint faulty code. In order to debug a program, Visual Studio .NET must

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

For the debugger to do its job well, it must make as few changes as possible to the operation of the program, so simply attaching Visual Studio .NET's debugger does not have much immediate effect. In order to examine a program's state and behavior, you must suspend its execution, so you will need to give VS.NET the criteria under which it should freeze the application and show you what is going on.

You can control program execution in three ways with the debugger. Breakpoints enable you to bring the program to a halt on selected lines of code. You can configure the debugger to suspend execution when particular error conditions occur. And once the program has been brought to a halt, you can exercise fine control by single-stepping through the code.

As you would expect, Visual Studio .NET allows you to set breakpoints—requests to suspend the program when it reaches certain lines of code. You can set a breakpoint by placing the cursor on the line at which you want execution to stop and pressing F9. F9 will toggle the breakpoint—if the line already has a breakpoint set, F9 will remove it. (You can also toggle breakpoints by clicking in the gray column at the left of the editor.) Visual Studio .NET indicates that a breakpoint has been set by placing a red circle to the left of the line, as Figure 3-6 shows. It can also optionally color the line's background—you can configure this with the Options dialog. (Use Tools → Options, and select the Fonts and Colors properties in the Environment category.)

Figure 3-6: A breakpoint

Breakpoints have an effect only when the debugger is attached—if you run a program outside of the debugger, it will not stop at a breakpoint.

Old-style compiled-in breakpoints that work under any circumstances are still available if you need them. With .NET applications, you simply call the

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The ability to watch the progress of a program's execution line by line is important, but debugging would be much harder if we were not also able to examine the program's state. Visual Studio .NET therefore provides us with a range of tools for examining a process's memory. We can access global variables, the stack (which contains local variables and parameters of the currently executing method and its callers), and raw memory.

Several windows can be used to display variables and expressions while single-stepping through code in the debugger. They all work in more or less the same way, displaying the name, value, and type of a number of expressions. They are all dockable tool windows. They all keep their value displays up-to-date as you single-step through the code, highlighting any changed values in red. The only difference between these various windows is the exact selection of expressions displayed.

Section 3.3.1.1: Watch windows

A watch window is a grid into which you can type arbitrary expressions. These will be evaluated whenever code is halted in the debugger and updated as you single-step. All expressions are evaluated with respect to the scope of the current line of code.

Figure 3-20 shows a watch window with two expressions. (New expressions are added by typing into the Name column in the blank line at the bottom of the grid.) The first expression, this, illustrates that the watch window allows objects to be expanded so that the individual fields can be shown. The second expression,

((Button)
sender).Text

, illustrates that we are not restricted to simple variable names—this is a snippet of C# that performs a cast on a variable and then retrieves a property.

Figure 3-20:

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The Visual Studio .NET debugger relies on having detailed information about your program. To be able to provide source-level debugging, it needs to know how compiled code relates to source code. In order to be able to evaluate expressions, it needs to know about the variables and types in use in your program. And for .NET programs, it needs the CLR's cooperation to be able to display the values of local variables and parameters.

The information required for debugging does not come for free. The symbols and line number information take up space. Making local variables and parameters available to the debugger places extra constraints on the compiler, reducing performance. Furthermore, this information makes it much easier to reverse engineer code. For all of these reasons, you will probably not want to ship debug versions of your programs.

With .NET, even release builds are relatively easy to reverse-engineer, because all symbol names apart from local variables are left in release builds. One way to mitigate this is to use an obfuscation tool. (VS.NET 2003 ships with such a tool.) Of course, the only thing that can stop the truly determined from reverse-engineering your applications is to not give them the applications in the first place.

When you create a new project, Visual Studio .NET will create at least two different configurations for that project, enabling you to build debug and release versions of the code. Release builds usually have no symbols beyond those required by the target technology. (For native Win32 applications, the only symbols will be those needed for DLL import and export tables. For .NET applications, full type information, but not enough information to perform source-level debugging, will be present.) Release builds are also normally compiled with full optimizations enabled. (And in the case of .NET applications, where most of the compilation process is done by the CLR, the binary will be marked as nondebug, enabling the CLR to perform full optimizations.) Optimizations are disabled in debug builds because they tend to interfere with the debugger's ability to display the program's state.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

So far we have looked at debugging relatively straightforward solutions. Visual Studio .NET is capable of debugging multiple solutions simultaneously, even when those solutions span multiple threads, processes, languages, technologies, and even multiple machines. While such projects require a little more configuration, it is much easier to debug these scenarios than it was with previous versions of Visual Studio.

The .NET runtime is often referred to as the CLR—the Common Language Runtime. It is so called because all languages that target the .NET platform share the same runtime environment. One of the benefits of this is unified debugging. If your solutions contain components written in multiple languages, then as long as those components have all been built with debug support enabled, traversing language boundaries works seamlessly. No special configuration is required.

When crossing technology boundaries, however, you will need to make sure that things are set up correctly before you start. So if your system contains a mixture of .NET and native Win32 code, you will need to ensure that your startup project's configuration enables both types of debugging, as described earlier. (Or if you are attaching to an existing process, you must make sure that both the Common Language Runtime and the Native options are checked in the Attach to Process dialog.)

T-SQL is a special case. You can set breakpoints in stored procedures and step through T-SQL code just like other languages. However, T-SQL is different, in that you cannot step directly into it from another language. Stored procedures are usually invoked through some data access API, such as ADO.NET or OLE DB, using code such as that shown in Example 3-3.

Example 3-3. Calling a stored procedure from C#

. . .
cmd.CommandType = CommandType.StoredProcedure;
IDataReader dr = cmd.ExecuteReader(  );
. . .

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Visual Studio .NET provides an exceptionally powerful debugging environment. It can debug normal executable applications, ASP.NET applications, client-side script, and T-SQL stored procedures. Furthermore, it can manage all of these from within a single debugging session, even when these components are running on different machines. For all of these different technologies, it provides extensive facilities for controlling the flow of execution and monitoring the state of your programs.

Now that we have looked in detail at how to manage, build, and debug solutions in VS.NET, it is time to look in more detail at some specific project types, so in the next chapter we will be examining web projects.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Microsoft wanted its first truly integrated development environment to be usable for all layers of your application; they did a pretty good job at making that happen. Class libraries, Windows applications, database code, web applications, and web services can all be developed and debugged in VS.NET, even though these various components may be distributed across multiple machines. Web applications and web services get a certain amount of special handling—VS.NET can communicate with local or remote web servers on your behalf in order to create and debug the web-based parts of your distributed systems. Also, certain aspects of the development process are different for web projects than for other project types, so this chapter will outline the basic operation of VS.NET when dealing with web projects.

When you create a new project, the project template you choose determines whether your project is web-based. A web-based project is one that is accessed or managed via a web protocol, such as HTTP, HTTPS, or FTP. The list of web project templates is listed in Table 4-1.

Table 4-1: Web-based projects
Project template	Managed	Description	Output
ASP.NET Web Application (C#/VB/J#)	Yes	ASP.NET Web Forms Application	Managed DLL and content files
ASP.NET Web Service (C#/VB/J#/MC++)	Yes

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

When you create a new project, the project template you choose determines whether your project is web-based. A web-based project is one that is accessed or managed via a web protocol, such as HTTP, HTTPS, or FTP. The list of web project templates is listed in Table 4-1.

Table 4-1: Web-based projects
Project template	Managed	Description	Output
ASP.NET Web Application (C#/VB/J#)	Yes	ASP.NET Web Forms Application	Managed DLL and content files
ASP.NET Web Service (C#/VB/J#/MC++)	Yes	ASP.NET Web Service	Managed DLL and content files
ASP.NET Mobile Web Application	Yes	ASP.NET Web Forms Applications for mobile devices	Managed DLL and content files
Empty Web Project (C#/VB/J#)	Yes	An empty project to which to add source and content files	Managed DLL and content files
ATL Server (VC++)

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Visual Studio .NET allows managed (.NET) web projects to be written in C#, VB.NET, or J#. Each of these languages has four web project templates: ASP.NET Web Application, ASP.NET Web Service, ASP.NET Mobile Web Application, and Empty Web Project. (Mobile Web Applications are not available in VS.NET 2002.)

Visual C++ has only one .NET web project type: ASP.NET Web Service. However, the way it works within VS.NET is more like the other unmanaged Visual C++ web projects than the C#, VB.NET, or J# managed projects. We will therefore describe that project type in Section 4.3.'

The ASP.NET Web Application template is used for building web applications that will be accessed from a normal web browser. The ASP.NET Web Service template is used to build web services—programs that present a programming interface instead of a user interface, but which are still accessed using HTTP. The ASP.NET Mobile Web Application template is designed for building web applications that will be accessed from a web browser on a mobile device such as a PDA or mobile phone. The Empty Web Project template can be used to build any kind of web application.

These four template types are very similar to one another—they manage and build their files in much the same way. The only differences between them are the default set of files that are added to the project initially. For the ASP.NET Web Application project, the main file added to the project is an ASP.NET Web Form named WebForm1.aspx, while for a Mobile Web Application, the main form is called MobileWebForm1.aspx. (Mobile Web Applications also have an additional reference to System.Web.Mobile.) For ASP.NET Web Service projects, the main file is Service1.asmx, which acts as the main web service entry point. An Empty Web Project contains no files at all to start with.

VS.NET treats all of these project types in exactly the same way once they have been created. So for the rest of this section, we will not distinguish between the different types of managed web projects.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

VC++ web projects act more like nonweb VS.NET projects than like the managed web projects described earlier. All of the solution, project, and source files are kept on the local hard disk and not the web server. When you build a VC++ web project, all of the usual build and debug build directories are used, and not the local web cache folder. The only real difference between a nonweb project and a VC++ web project is that a VC++ web project has a final build step that copies the appropriate DLLs and content files to the web server.

Creating a new unmanaged web project is similar to creating a nonweb project. Unlike with managed web projects, you do not specify a remote web server in the New Project dialog—you just specify a folder on the local filesystem as usual. When you build an unmanaged web project, VS.NET communicates with IIS via DCOM (Distributed Component Object Model) and creates the appropriate web application for your project. (By default, it will use the project name, but you can change this in the Project Property Pages dialog—in the Web Deployment settings, the General section contains a Virtual Directory Name property that you can use to control where VS.NET will send the build output.)

The two basic types of VC++ web projects are ATL Server and ASP.NET Web Service (or Managed C++ Web Service as it was called in VS.NET 2002). Although they create different kinds of output, these projects interact with the web server in the same way.

ATL Server: An ATL Server project creates a new web application whose main executable is an ISAPI (Internet Server Application Programming Interface) extension DLL. This ISAPI extension responds dynamically to HTTP requests. There are two ATL Server project templates. ATL Server Project creates an ISAPI DLL that uses .srf files to create dynamic HTML UIs. ATL Server Web Service creates an ISAPI DLL that exposes a web service via SOAP (Simple Object Access Protocol). See

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|

Table of Contents

Section 3.3.1.1: Watch windows