The Internet Encyclopedia (Volume 3)

P1: JDT

WL040C-44 WL040/Bidgoli-Vol III-Ch-51 June 23, 2003 16:33 Char Count= 0

632 VISUALBASICSCRIPTINGEDITION(VBSCRIPT)

Basic programmers who want to script under .NET (e.g.,

in ASP.NET pages) use the same Visual Basic .NET lan-

guage as when authoring stand-alone code meant to be

compiled and run as a .EXE file. This adds considerable

power for script authors to exploit, but it arguably does

so at the cost of increased complexity.

The .NET framework itself, downloadable for current

versions of Microsoft Windows as the .NET framework

redistributable, is a set of extensible object classes pro-

viding comprehensive access to the events and services

of the Microsoft Windows platform. Because it supports

multiple programming languages through a single CLR,

all .NET supported languages offer the same full platform

access and full support for object-oriented programming,

including inheritance and polymorphism. It is no longer

necessary for host applications to provide scaled down ob-

ject models specifically for scripting. The .NET framework

implements classes through the use of “Namespaces” and

“Assemblies.” In .NET terms, an assembly is any collec-

tion of classes and resources, whether private or shared,

that has been compiled into MSIL. Thus, any .NET appli-

cation compiled into a MSIL library or executable is also

known as an assembly. .NET assemblies are conceptually

similar to JAVA packages.

The intrinsic foundation classes of the.NET framework

are bundled into approximately 30 separate assemblies

(DLL files in this case) loaded onto the host system dur-

ing installation of the .NET framework. Each of these as-

semblies is then available to be referenced in code through

the inclusion of its namespace. (The two top-level intrinsic

namespaces of the .NET framework are “Microsoft” and

“System.” Most applications routinely reference mem-

bers of the System namespace. The Microsoft names-

pace, dealing with more esoteric events and functions,

is referenced less often.) Thus, for example, to imple-

ment the Show method of the MessageBox class included

in the System.Windows.Forms.dll assembly, a Visual Ba-

sic.NET application might begin by importing the System.

Windows.Forms namespace as shown in Listing 6.

Listing 6:A simple message box application in Visual

Basic.NET.

Imports System.Windows.Forms

REM Module MyApp

REM Houses the application’s entry point.

Public Module MyApp

REM Main is application entry point.

Sub Main( )

System.Windows.Forms.MessageBox.Show_

("Press OK to Finish.")

End Sub

End Module

Note that classes of a given assembly (including applica-

tions compiled to MSIL) can be explored using the com-

mand line MSIL disassembler utility, ildasm.exe, provided

with the .NET framework software development kit

(SDK)—thus, “ildasm.exe System.Windows.Forms.dll.”

While the .NET framework does preserve the concepts

of scripting engines and scripting hosts, the details are

changed quite a bit. Most notably, .NET compiles all code,

even script, through two stages before running. The first

compilation stage is from application-native language

(e.g., Visual Basic, JScript, and C++) to MSIL. The MSIL

version of an application is CPU-portable and must be

further compiled by a JIT process into native machine

code before execution. The second, JIT compile to na-

tive machine code is handled within the .NET framework,

is transparent to the programmer and can largely be ig-

nored in the context of this discussion. The first compila-

tion to MSIL has more significant implications for script

authors.

For script applications (e.g., ASP.NET), compilation to

MSIL is made by the new .NET scripting engines. This

means that when a host relies on a scripting engine, no ex-

plicit compile step is required. It also means that compile

errors (e.g., basic syntax errors) are reported separately

from runtime errors and before application execution has

begun, a definite benefit when debugging complex appli-

cations. It also means that performance can be detectably

different the first time a script application is run after code

changes. The scripting engine and host application de-

termine automatically whether the code has been altered

since last compile. If so, a compile to MSIL is made be-

fore execution. If not, the previously compiled version is

used (saving time). Also, all languages compile to the same

version of MSIL, requiring more commonality among the

languages regarding data typing, passing of parameters,

and runtime (intrinsic) functions. These changes, which

have been implemented in part to reduce chance of mem-

ory leaks, overflows, and other hazards to execution safety

and security, have resulted in a number of Visual Basic lan-

guage changes, e.g., strong data typing (no more variants),

explicit declaration of all variables, procedure parameters

passed by value by default rather than by reference as pre-

viously, changes to or replacement of familiar functions,

and modification of object models.

Finally, while scripting engines for both JScript and

Visual Basic ship with the .NET framework, at this time

only one scripting host, that for IIS (i.e., for ASP.Net) is

included. There is as yet no .NET equivalent to the WSH.

In the meantime, however, the .NET framework does in-

clude command-line compilers for both Visual Basic and

JScript, and this is sufficient to allow hard-core script au-

thors to still use their favorite plain text editor to pro-

gram Windows using Visual Basic or JScript (as opposed

to authoring in Visual Studio.NET or Visual Studio for

Applications). Before running such scripts, however, they

must be compiled to MSIL. For Visual Basic code this

is accomplished by using vbc.exe, e.g., for the script in

Listing 6,

vbc.exe/t:winexe/r:System.Windows.Forms.dll

MyScript.vb

where “MyScript.vb” is the name of the file containing the

code in Listing 6. Note the /r command line switch, which

is used to explicitly point to the location of an imported

namespace.