There's a misunderstanding in the development community that you somehow need a lot of fancy software to create a .NET application. In truth, the .NET Framework installation provides everything you need, including the compiler. The reason to use Microsoft's fancy IDE is to obtain the automation it provides, as well as the templates, tools, and resources that the IDE includes.

Now, I wouldn't want to write my next database application this way, but I do write short, utility-type applications all the time at the command line. It's a handy skill to have, because you can often use these mini-applications to replace more cumbersome automation methods, such as scripts and batch files. In addition, the compiled application is less prone to modification by less skilled users, which gives you a measure of protection from prying eyes.

To use this technique, you need a pure text editor. Any editor like Notepad will do. You can't use Word, or any editor with formatted text; the formatting will cause problems during the compilation process. In addition, you must have a version of the .NET Framework installed that includes support for JScript.NET. This article relies on the latest .NET Framework 2.0, but you can also easily use this technique with the 1.1 version. (I didn't test this technique with the .NET Framework 1.0 because so few people installed it.)

Working with the JSC Compiler

The JSC compiler is a command line utility that turns your JScript code into an executable file. Don't confuse JScript with JavaScript; some people do, since you can use JScript on Web pages. Although the two support similar programming constructs and you can indeed create an equivalent of a JavaScript script using JScript, the two also have significant differences. For one thing, you can't access the .NET Framework from JavaScript. You'll find the JSC compiler in the \WINDOWS\Microsoft.NET\Framework\v1.1.4322 or \WINDOWS\Microsoft.NET\Framework\v2.0.50727 folder. To use this compiler, you type JSC, followed by a list of source files. Specify options for compiling a specific file by including them immediately before the source file name, like this:

jsc [options] <SourceFiles> [[options] <SourceFiles>...]

The JSC compiler supports a wealth of compilation options at the command line, but you'll use some options more than you use others. Type JSC /? and press Enter to see a list of all of the options that JSC supports. Here's the options that you'll commonly need to create applications at the command line (the list isn't complete):

• /out:file - Determines the name of the output file. The default is to use the name of the source file as the name of the output file, and to add the required extension, such as EXE or DLL.
• /t[arget]:exe - Creates a console application, one that executes at the command line. A console application can still use message boxes and other graphical elements, but it starts execution at the command line. Most console applications have the same appearance as the command line utilities that administrators have always used; the option to choose if you want to create an application that looks and acts much like a script or batch file.
• /t[arget]:winexe - Creates a Windows application. This application begins running in a windowed environment. This option produces about the same result as running a JavaScript application using WScript instead of CScript.
• /t[arget]:library - Creates a library. A library is a method of storing code for use in multiple applications. The result is a DLL file. You can use DLLs to store routines that you commonly use, so you don't have to keep typing them repeatedly. In fact, this command line switch demonstrates one reason you might want to use JScript in place of a script or batch file; code reuse is far easier in this environment.
• /autoref{+ | -} - References any assemblies that you define using an import statement within your source code. The complier automatically uses the most current version of the assemblies. You can turn this feature off by using the /autoref- command line switch. In this case, you must manually reference the required assemblies using the /reference command line switch.
• /lib:path - Specifies additional directories that the compiler should use to search for references.
• /r[eference]:FileList - References one or more files for inclusion in the resulting application. A reference file provides code resources for the application. For example, if you reference the System.Windows.Forms.DLL file, you can create message boxes within your application.

Mind you, JSC includes all kinds of other command line switches that this article doesn't discuss. For example, there are several command line switches for using standard resource files, but unless you already have these resource files, the command line options are useless without an IDE. (Now you understand why Microsoft's IDE could be important to your application development needs.) It's also possible to add debugging information to your executable, but again, this option is only useful if you have a debugger to use, which means having Microsoft's IDE available. In short, many of the options are interesting, but probably not too useful at the command line.

Comparisons of Containers

JScript supports all the constructs that you would expect when working with ECMAScript. Consequently, you can use JScript as part of a Web page, or anywhere else that you can use JavaScript. In fact, the following script works equally well using JavaScript or JScript simply because it adheres to the ECMAScript standard.

<script type="text/javascript">
   document.write("Hello");
</script>

All you'd need to do is change the type to text/jscript to make the conversion. However, this script runs on a Web page; the browser provides the container in which the script runs. The container you use to execute a script is important because the container determines which objects are available for use. The document object shown in this example is part of the browser container.

When working at the command line, JavaScript scripts tend to use the WScript objects because you use the CScript or WScript utility to run the scripts. These two utilities provide access to the Windows Scripting Host (WSH) container. In other words, JavaScript at the command line relies on a different container from JavaScript in a Web page. The same Hello script looks like this for JavaScript at the command line:

WScript.echo("hello");

JScript relies on the .NET Framework as a container. To produce the same result using JScript at the command line, you have to consider the container in which JScript executes. Even though all of the same ECMAScript standards apply, the use of a different container makes a difference in the use of objects. Here's the code for a JScript Hello at the command line:

import System.Windows.Forms;
MessageBox.Show("Hello");

You compile this script to use it. Type JSC Hello.JS at the command line and press Enter (assuming you have the .NET Framework installed on your system; you can download the latest version here). The import statement in this example imports a particular class. The System.Windows.Forms namespace contains the MessageBox.Show() method used to display a message. After you compile the application, you run it as you would any other application by typing Hello and pressing Enter.

The point is that you still use all of the same constructs when working with JScript and the .NET Framework. For example, a For loop doesn't change simply because you've changed environments. You declare variables using the same techniques. All of the equations you used in the past still work in the .NET version of your application. Only the objects change to meet the requirements of the new container.