Datasheet

22
❘
CHAPTER 1 VISUAL STUDIO 2010
As noted, Visual Studio 2010 provides support for remote debugging, although such debugging is involved
and not confi gured for simple scenarios. Remote Debugging can be a useful tool when working with an
integration test environment where developers are prevented from installing Visual Studio but need to be
able to debug issues. However, you shouldn ’ t be limited by just using the debugger for understanding what is
occurring in your application at runtime.
Another alternative for determining what is occurring within a remote application is using the
Debug and Trace
classes. As noted in Chapter 6, the Debug and Trace classes combined with effective error handling, often make it
faster and easier to determine remote errors then setting up the remote debugger. However, for those environments
where an application runs only on a central server, and for which developers have the necessary permissions to
run the debugger but not install a copy of Visual Studio, it is possible to leverage remote debugging.
Finally, as might be expected, users of Visual Studio 2010 who work with multiple languages, and who use
tools that are tightly integrated with SQL Server, have additional debuggers. The fi rst of these is support
for debugging outside of the CLR — what is known as unmanaged code . As a Visual Basic developer, the
only time you should be using unmanaged code is when you are referencing legacy COM components.
The developers most likely to use this debugger work in C++.
The next option turns on support for SQL Server debugging, a potentially useful feature. In short, it ’ s possible,
although the steps are not trivial, to have the Visual Studio debugging engine step directly into T - SQL stored
procedures so that you can see the interim results as they occur within a complex stored procedure.
References
It ’ s possible to add additional references as part of your project. Similar to the default code fi les that are
created with a new project, each project template has a default set of referenced libraries. Actually, it has
a set of imported namespaces and a subset of the imported namespaces also referenced across the project.
This means that while you can easily reference the classes in the referenced namespaces, you still need to
fully qualify a reference to something less common. For example, to use a StringBuilder you ’ ll need
to specify the fully qualifi ed name of System.Text.StringBuilder . Even though the System.Text
namespace is referenced it hasn ’ t been imported by default. For Windows Forms applications targeting
.NET 4, the list of default referenced namespaces is fairly short, as shown in Table 1 - 4.
TABLE 1 - 4: Default References in a New Project
REFERENCE DES CRI PT ION
System Often referred to as the root namespace. All the base data types ( String ,
Object , and so on) are contained within the System namespace. This
namespace also acts as the root for all other System classes.
System.Core This dll contains a collection of namespaces, some of which are required to support
LINQ to in - memory objects, as well as support for several OS - level interfaces.
System.Data Classes associated with ADO.NET and database access. This namespace is the
root for SQL Server, Oracle, and other data access classes.
System.Data
.DataSetExtensions
Defi nes a collection of extension methods used by the core DataSet class.
These are used when working with LINQ to DataSets.
System.Deployment Classes used for ClickOnce Deployment. This namespace is covered in more
detail in Chapter 34.
System.Drawing Provides access to the GDI+ graphics functionality
System.Windows.Forms Classes used to create traditional Windows - based applications. This
namespace is covered in more detail in Chapters 14 and 15.
System.XML Root namespace for all of the XML classes
System.XML.Linq Root namespace to support the Language Integrated Query (LINQ) native
language queries for XML data sources.
CH001.indd 22CH001.indd 22 4/5/10 11:56:37 AM4/5/10 11:56:37 AM