18
❘
CHAPTER 1 VISUAL STUDIO 2010
This presented a challenge because this wasn ’ t the situation for any other set of Visual Studio settings; and
Visual Basic developers were sometimes caught - out when sending what they thought was the latest build of
their source code. If on their last “ build ” they were testing a fi x and starting the debugger, then they hadn ’ t
rebuilt the release version. Thus, instead of sending a copy of the released version of their application with
that last tested fi x, they were really sending the last release build made before the fi x. The return of these
settings means that you, as the developer, have explicit control over the type of executable (release or debug,
x64 or x86) that Visual Studio produces.
If you don ’ t see these drop - downs in your display, you can restore them by selecting Tools
➪ Options, and
then turning on the Advanced compile options. The main reason to restore these options has to do with two
key features that are dependent on this setting. The fi rst is Edit and Continue, which provides the capability
to make a change in executing code and without restarting, having that change available in your running
code while you continue to debug. This is a great tool for simple mistakes that are found during a debug
session, and it is only supported for x86 (32 - bit) targeted assemblies. This means you must explicitly target
x86, as shown in Figure 1 - 7.
In Visual Studio 2008, the default was to target AnyCPU, but this meant that on a 64 - bit developer
workstation, Visual Studio was targeting a 64 - bit assembly for your debug environment. When working
on a 64 - bit workstation, you must explicitly target an x86 environment in order to enable both Edit and
Continue as well as the other dependency, COM - Interop. The second key feature related to x86 is COM.
COM is a 32 - bit protocol (as you ’ ll see in Chapter 28 on COM - Interop, so you are required to target a
32 - bit/x86 environment to support COM - Interop.
Aside from your default project fi le output directory, this page contains several compiler options. The Option
Explicit, Option Infer, and Option Strict settings directly affect your variable usage. Each of the following
settings can be edited by adding an
Option declaration to the top of your source code fi le. When placed
within a source fi le each of the following settings applies to all of the code entered in that source fi le, but only
to the code in that fi le:
Option Explicit — This option has not changed from previous versions of Visual Basic. When
enabled, it ensures that every variable is explicitly declared. Of course, if you are using Option Strict,
then this setting doesn ’ t matter because the compiler won ’ t recognize the type of an undeclared
variable. To my knowledge, there ’ s no good reason to ever turn this option off unless you are
developing pure dynamic solutions, for which compile time typing is unavailable.
Option Strict — When this option is enabled, the compiler must be able to determine the type of each
variable, and if an assignment between two variables requires a type conversion — for example, from
Integer to Boolean — then the conversion between the two types must be expressed explicitly.
Option Compare — This option determines whether strings should be compared as binary strings or
whether the array of characters should be compared as text. In most cases, leaving this as binary is
appropriate. Doing a text comparison requires the system to convert the binary values that are stored
internally prior to comparison. However, the advantage of a text - based comparison is that the character
“ A ” is equal to “ a ” because the comparison is case - insensitive. This enables you to perform comparisons
that don ’ t require an explicit case conversion of the compared strings. In most cases, however, this
conversion still occurs, so it ’ s better to use binary comparison and explicitly convert the case as required.
Option Infer — This option was new in Visual Studio 2008 and, was added due to the requirements
of LINQ. When you execute a LINQ statement, you can have returned a data table that may or may
not be completely typed in advance. As a result, the types need to be inferred when the command
is executed. Thus, instead of a variable that is declared without an explicit type being defi ned as an
object, the compiler and runtime attempt to infer the correct type for this object.
Existing code developed with Visual Studio 2005 is unaware of this concept, so this option will be off
by default for any project that is migrated to Visual Studio 2008 or Visual Studio 2010. New projects
will have this option turned on, which means that if you cut and paste code from a Visual Studio
2005 project into a Visual Studio 2010 project, or vice versa, you ’ ll need to be prepared for an error in
the pasted code because of changes in how types are inferred.
➤
➤
➤
➤
CH001.indd 18CH001.indd 18 4/5/10 11:56:30 AM4/5/10 11:56:30 AM