Up and Running with the SSCLI
Volume Number: 19 (2003)
Issue Number: 11
Column Tag: Programming
Casting your .NET
Up and Running with the SSCLI
by Andrew Troelsen
Exploring .NET development on Mac OS X
Let there be code
In the last issue, you were introduced to a number of specifications that qualify the .NET platform, collectively termed the Common Language Infrastructure (CLI). As mentioned, these specs (no matter how detailed) do us little good until they are implemented in a usable code base. In this installment, you will obtain, configure and explore one such implementation of the CLI named the Shared Source CLI (SSCLI). Although the SSCLI originates from Microsoft Corporation, the contained source code is designed to build on Win32, Mac OS X and other FreeBSD-based distributions.
the Role of the Shared Source CLI (SSCLI)
Before we can begin creating our own custom .NET assemblies (see previous issue) our first task is to obtain a viable implementation of the CLI. For the time being we will concentrate on a research-focused distribution provided by Microsoft named the SSCLI (which also is referred to by its code name Rotor). The SSCLI is 'research-focused' in that it is not intended to be used to as a production level development platform (though on some levels, it most certainly could be), but rather as a tool to explore the C# programming language and the technologies defined by the CLI itself.
The SSCLI does not ship with an implementation of ADO.NET (.NET's data access API), ASP.NET (.NET's Web development API) or Windows Forms (.NET's GUI desktop API). On the plus side, the SSCLI does supply a fully functionality C# compiler, a JScript.NET compiler (which is, in fact, written using C#), a VES implementation and core class libraries (described a bit later in this article). As you would also expect, the SSCLI ships with a number of command line utilities (security tools, compilers, assembly-tweaking tools and so forth) that allow you to interact with the platform itself.
The source code contained within the SSCLI is a blend of C++, C# and assembler instructions (used for only the very lowest of low-level OS-specific details). A majority of the C++ code represents a key aspect of the SSCLI termed the Platform Adaptation Layer (PAL), which abstracts away OS-specific details (more details in just a moment). On a related note, the C++ programming language is used to build the C# compiler. Beyond this however, C# makes up a majority of the source code, which is used to implement a vast majority of the SSCLI base class libraries as well as the JScript.NET compiler.
Rest assured that by taking the time to work with the SSCLI, you will not only gain a solid understanding of the C# programming language, but core aspects of the .NET runtime engine and the programming tools you will make use of on a daily basis. As you would guess, this will provide an excellent foundation when examining other implementations of the CLI such as Portable .NET, Mono and Microsoft's CLR.
Defining 'Shared Source'
The 'SS' in SSCLI refers to the fact that the code base may be extended, modified, hacked, compiled and shared among developers. Thus, if you wish to add additional functionality to the C# compiler, change the way the execution engine handles memory allocations or use the code representing the JScript.NET compiler as the basis for a new .NET language compiler (Logo.NET anyone?), you may do so! However, what you may not do is redistribute a modified SSCLI code base for monetary profit (after all, shared source is not quite open source).
Throughout this series, it is my assumption is that most of you are more interested in using the SSCLI as a vehicle to understand the .NET platform and C# language rather than to alter the existing code base. Given this, I do not intend to spend too much time drilling into the low-level SSCLI implementation code, unless it provides insights into the discussion at hand (whatever that may be). However if you do intend to tweak and recompile the SSCLI source code files, be sure to read the (one-page) license agreement (license.txt) located under the root /sscli folder. Here you will find more details regarding the shared source mindset.
Your Friend, the PAL
As mentioned, a major chunk of C++ source code represents the Platform Adaptation Layer, or PAL. The role of the PAL is to emulate a subset of the Win32 APIs for use on diverse operating systems. The operative word in that last sentence is subset. Basically, the PAL is a platform neutral API which exposes core services such as file IO, networking services, error handling, threading and so forth. The trick however is that although the names of these functions map directly to Win32 APIs, their implementation will differ wildly based on the underlying target operating system.
The next point to be made regarding the PAL is the fact that the /sscli/pal folder contains two subdirectories: unix and win32. As you would guess, if the SSCLI were built on a Win32-based machine, the code within the win32 folder is used to build the PAL. Under Unix-based systems (which of course includes Mac OS X's Darwin), the unix folder is consulted during the compilation process. In either case, it is worth mentioning that not all of the functions defined by the PAL have an exact match in the Win32 API. To be sure, there are a small number of functions (all of which have the 'PAL_' prefix), which are particular to the SSCLI itself.
Again, if you don't intend to modify the SSCLI or port the code base to a new operating system, you can basically be blissfully unaware of the gory details regarding the Platform Adaptation Layer. However, if you wish to take a detailed look at the functions defined by the PAL, you can read the "PAL guide" which is documented in /sscli/docs/techinfo/pal_guide.html. If you wish to view the exact C++ header file that prototypes each function (and the related C++ structures, enumerations and typedefs), examine the rotor_pal.h file located under the /sscli/pal folder.
Downloading the SSCLI
To obtain the SSCLI, launch your Web browser of choice (Safari, of course) and navigate to http://msdn.microsoft.com/net/sscli. Scroll down to the end of this page and download the files listed in Table 1 to your folder of choice. Be very aware that the SSCLI will not build if the local directory path contains any spaces. Therefore a subfolder in your Developer folder named "My_DotNet_Stuff" is fine, while "My Dot Net Stuff" is quite problematic as far as the build process is concerned (this is true of Unix builds in general).
File to Download Meaning In Life
sscli_20021101.tgz This file contains the code needed to build a working implementation of
the CLI, including C# and JScript.NET compilers.
sscli_ref_20021101.tgz This file extracts to an HTML based class library browser that documents
all of the types supplied by the SSCLI.
Table 1. The file of the SSCLI
As you will surly notice, the size of these files are quite large. Again, given that the SSCLI is a research-focused implementation of the CLI, you will be downloading a huge amount of raw source code. Later in this series when we shift away from the SSCLI to a 'real-world' implementation of the CLI (such as Portable .NET) you will be pleased to find more manageable downloads.
Obtaining and Installing Tcl/Tk
Before you unpack and build the SSCLI, you will also want to make sure that your Macintosh development machine is equipped with Tcl/Tk. First two questions: "What is Tcl/Tk and why do I need it?" Tcl/Tk is a GUI toolkit and scripting language that can be used to build traditional desktop applications. As mentioned, the SSCLI does not ship with an implementation of Windows Forms, however several sample applications make use of the Tk 8.4.0 widget set to illustrate how the SSCLI can be extended to support alternative GUI toolkits. Therefore, if you wish to run the supplied Tcl/Tk samples (which we will do at a later time), you will need to install this Unix package.
Next question: "Where do I obtain Tcl/Tk?" www.scriptics.com is the official web site for Tcl/Tk, and from here you can download the latest binaries. If you prefer a Mac-friendly alternative however, you can make use of Fink (and/or Fink Commander) to download and install Tcl/Tk with minimal fuss and bother.
This leads me to address the final possible question you might have at this point: "What is Fink?" (if you already know the answer, feel free to begin your download now). Given that the Mac OS is a Unix-based operating system, the Fink project was created to provide a simple way to install Unix software on the Macintosh. While Fink is a command line driven tool, the complementary Fink Commander application provides a GUI shell to the same functionality (both can be downloaded from http://fink.sourceforge.net). Assuming you have Fink Commander up and running, simply do a search for Tcl (Figure 1) and install the tcltk binary using the Binary | Install menu option.
Figure 1. Obtaining Tcl/Tk via Fink Commander
Once you have installed this package, you will find libtcl8.4.dylib and libtk8.4.dylib libraries have been installed (by default) under your /sw/lib folder.
Building the SSCLI
Due to the fact that you are reading MacTech, you are no doubt a software developer (hobbyist or otherwise), and given this fact, I'd bet you have latest and greatest Mac OS programming environment. Nevertheless, do know that the SSCLI expects the following minimal software/hardware requirements:
- Mac OS X version 10.2 or higher.
- The Apple Developer Tools.
- The BSD subsystem installed (this is done by default when installing OS X).
- 256 MB memory at minimum, 512 MB (recommended), 1 GB (the best!).
- One gigabyte of free disk space (remember...this is a research distribution).
Building the SSCLI is very straightforward and only involves interacting with two files: env.csh and buildall. Env.csh is a Unix-based shell script that defines a number of platform-specific environment variables required by the SSCLI. The buildall file, as you would expect, is a script that drives the build process for each of the contained subdirectories. This being said, perform the following steps to build the SSCLI on your development machine:
- Extract sscli_20021101.tgz (either StuffIt or the gnutar utility will do).
- Open a Terminal and navigate to the sscli directory.
- Source the env.csh file at the command line (e.g., type: source env.csh).
- Finally, build the SSCLI by typing ./buildall (within the same Terminal session).
At this point, the build process begins and will continue for some time (now would be a good time to catch up on your e-mails or other such ToDos). If you are interested in examining further details of the build process, check out the building_sscli.html, env.html and buildall.html documents located under sscli/docs/buildtools/. In any case, once the build process is complete, your Macintosh development machine is ready to plunge into the .NET universe.
Learning the Lay of the Land
Next up, let's take a moment to examine the generated directory structure. Using the Finder, open up the root directory of your SSCLI installation. To be sure, the installation process generates an elaborate directory structure, however Table 2 describes some of the key folders to be mindful of.
SSCLI Subfolder Meaning In Life
/build/v1.ppcfstchk.rotor This is the root folder that contains the compiled tools
and various SSCLI class libraries.
/build/v1.ppcfstchk.rotor/assembly/GAC The location of the Global Assembly Cache (GAC) that
contains a number of 'shared' assemblies. As seen in a
later article, a single copy of a shared assembly can be
consumed by multiple .NET client applications.
/build/v1.ppcfstchk.rotor/config Contains various XML-based SSCLI configuration files.
/clr/src/bcl/system Contains the C# source code files for the base class
libraries.
/clr/src/csharp Contains the C++ source code
/clr/src/ilasm for the C# compiler (csc), CIL
/clr/src/ildasm compiler (ilasm) and CIL
/clr/src/fusion dissassembler (ildasm). The fusion subfolder contains
code that allows the SSCLI to bind to specific version of
a .NET assembly (more details later).
/docs You guessed it, here are a number of HTML based
documentation files for the C# compiler, SSCLI development
tools and the underlying infrastructure. The index.html
file (located in /docs) is the 'home page' for all other
documentation.
/jscript C# source code for the JScript.NET compiler.
/pal C++ source code for the Platform Adaptation Layer (PAL).
/samples Various sample programs to build, modify and execute
within the SSCLI.
/tests Numerous source code files that can be used to test a
modified SSCLI distribution.
/tools These are tools used during the build process of the SSCLI,
not tools for building SSCLI applications!
Table 2. A partial listing of /sscli subdirectories
A few pages ago, you were introduced to the role of the /pal folder. I would also like to encourage you to check out the /samples folder. Here you will find numerous C# sample applications that illustrate programming with the SSCLI base class libraries (/sscli/samples/samples_index.html provides details regarding each sample application).
The next folder to be aware of at this point is the all-important /docs folder and the index.htm file it contains. When you open this file, you will find an exhaustive list of all of the documentation files for this CLI distribution. I highly recommend you save this file to your browser's Favorites list, as you will come here time and time again to learn about the tools, samples and technologies provided by the SSCLI.
Installing the SSCLI Online Documentation
The next configuration task is to extract the SSCLI online help contained within sscli_ref_20021101.tgz. Once you have extracted this binary (again, either StuffIt or gnutar will do), you will find a file named ClassLibrary.html within the root directory. As you would guess, this file contains links to each of the namespaces of the SSCLI, the highlights of which can be seen in Table 3.
Navigating the HTML-based help system is simple. To take things out for a test drive, click on the System.Xml link located towards the bottom of ClassLibrary.html. Once you do, you will find a 'home page' for the selected namespace, followed by a list of each type it contains (recall from the previous issue, the term 'type' is a generic way to describe classes, interfaces, enumerations, structures and delegates). Next, click on the XmlTextReader class type link. As you can see (Figure 2) you are provided with a C# definition and description of the type as well as the set of members it supports.
SSCLI Namespace Meaning In Life
System.CodeDom.Compiler 'Code DOM' is a very interesting technology which
System.CodeDom allows you to represent .NET coding constructs in
language neutral terms, and dynamically generate
and compile the persisted source code.
System.Collections.Specialized The collection-centric namespaces provide numerous
System.Collections types (ArrayList, Hasttable, etc) that allow you
to manage other types.
System.ComponentModel This namespace defines types that allow you to
establish how your custom components should be
treated at runtime (and possibly at design time).
System.Configuration.Assemblies As you will see later, .NET assemblies can be
System.Configuration configured using XML-based configuration files.
These namespaces define types that allow you to
interact with these files programmatically.
System.Diagnostics.SymbolStore These are fairly low-level namespaces that define
System.Diagnostics types that allow you to programmatically interact
with debugging and tracing details.
System.Globalization Here you will find types that help you deal with
issues of internationalization.
System.IO.IsolatedStorage As you would guess, the System.IO-centric
System.IO namespaces allow you to interact with your
machine's directory structure.
System.Net.Sockets Namespaces that allow you to program against
System.Net various network protocols.
System.Reflection.Emit The reflection namespaces allow you to dynamically
System.Reflection investigate, and generate, types at runtime.
System.Resoruces Contains types which allow you to embed resources
(such as string literals) into a given
.NET assembly.
System.Runtime.CompilerServices You will never care about this namespace unless
you are interested in building a .NET-aware
compiler.
System.Runtime.InteropServices.Expando Interoperability is the term used to describe the
System.Runtime.InteropServices process of communicating with native libraries from
within a .NET code base. These namespaces provide
types for such a task.
System.Runtime.Remoting.Activation The SSCLI provides numerous namespaces that allow
System.Runtime.Remoting.Channels.http you to build distributed systems using the .NET
System.Runtime.Remoting.Channels.Tcp remoting architecture.
System.Runtime.Remoting.Channels
System.Runtime.Remoting.Contexts
System.Runtime.Remoting.Lifetime
System.Runtime.Remoting.Messaging
System.Runtime.Remoting.Metadata.W3cXsd2001
System.Runtime.Remoting.Metadata
System.Runtime.Remoting.MetadataServices
System.Runtime.Remoting.Proxies
System.Runtime.Remoting.Services
System.Runtime.Remoting
System.Runtime.Serialization.Formatters.Binary As you will see in later articles, the SSCLI
System.Runtime.Serialization.Formatters.Soap provides a very sophisticated (but surprisingly
System.Runtime.Serialization.Formatters simple) object serialization architecture.
System.Security.Permissions As you would guess, these namespaces provide types
System.Security.Policy that allow you to interact with the .NET
System.Security.Principal security model.
System.Security
System.Text.RegularExpressions Regular expressions manipulation namespaces also
System.Text ship with the SSCLI.
System.Threading The System.Threading namespace defines types that
allow you to create and manipulate multi-threaded
applications.
System System is the root namespace in the SSCLI class
libraries. Here you will find a number of utility
types (Math, TimeZone, GC and so on), intrinsic
data types (String, Int32, Boolean) and common
exceptions.
System.Xml.Schema The SSCLI supplies a number of namespaces that
System.Xml.Serialization allow you to generate, read and manipulate
System.Xml XML-based data.
System.Xml.XPath
System.Xml.Xsl
Table 3. The SSCLI Base Class Libraries
Figure 2. Reading up on the XmlTextReader type.
I would also greatly encourage you to add the ClassLibrary.html link to your browser's Favorites list. Over the lifetime of this series, I am assuming you will dive in and check out details I do not have the space to directly cover on your own accord.
Setting Your a Development Environment
At this point I'm sure you are ready to build .NET applications using the SSCLI, however I have two final configuration settings, which while not required, will no doubt make your programming time more productive. The first tip is to define a set of shell aliases that allow you to quickly enable the SSCLI development environment (Listing 1). Using your text editor of choice, update your .tcshrc file with the following:
Listing 1. Defining shell aliases
# Change to SSCLI directory.
alias GoSscli 'cd ~/Web_Downloads/CLI/sscli'
# Change to SSCLI and source the env.csh file
alias DoSscli 'GoSscli; source env.csh'
The first alias, GoSscli, can be typed into a Macintosh Terminal to quickly navigate to the directory containing the SSCLI (of course, your path may vary, so modify accordingly). The second alias, DoSscli, leverages the first alias to change to the SSCLI directory and sources the env.csh file to establish the necessary environment variables. To be sure, when you intend to interact with any of the SSCLI command line tools (including the C# compiler) you must source this script or else contend with the dreaded "command not found" error.
To test your shell updates, close your current Terminal to commit the changes, open a new Terminal and execute the DoSscli command. You should see something like the following (Listing 2):
Listing 2: The result of commanding DoSscli
Last login: Thu Oct 9 14:32:48 on ttyp1
Welcome to Darwin!
[Andrew-Troelsens-Computer:~]andrewtroelsen% DoSscli
Fastchecked Environment
Now, type in the following command to see the list of options of the C# compiler:
csc -help
If all is well, you should find output similar to that of Figure 3.
Figure 3. Options of the C# Compiler
Configuring Project Builder
The final shortcut you will most likely wish to do is to enable Project Builder to edit C# code files. This one is a no-brainer, simply create a new file with a *.cs file extension (or locate one of the existing files provided by the SSCLI) and double click on the icon. From the resulting dialog box, simply choose Project Builder as the default application.
You will notice that Project Builder seems to recognize the syntax of C#, however don't get your hopes up. While code comments and string literals are realized, C#-specific keywords (such as 'namespace', 'using' or 'unsafe') do not receive such color-coding. Nevertheless, using Project Builder to edit C# code is an appealing alternative to command line editors such as vi or pico (at least in my opinion!)
The Basic Flow of SSCLI Development
Excellent! If you are still with me, you are now all set to build your first .NET application using the C# programming language. Regardless of which aspect of the SSCLI you are exploring or which type of application you are constructing, you will tend to follow a fixed set of tasks:
- Ensure you are working within a Terminal that has the SSCLI environment variables activated (thus the reason for the DoSscli alias).
- Send your C# source code (as well as any number of command line arguments) into the C# compiler, csc.
- Run your executable application using the Common Language Infrastructure Execution tool, clix.
Let's close this article with a complete example.
Building your First .NET Application
Our goal in this section is to create a code library (myLib.dll) that is consumed by a client application named myClient.exe. As briefly noted in the previous issue, .NET assemblies which end in a *.dll extension cannot be directly loaded by the runtime, but are rather loaded on demand by the client executable which request their services (you'll see many more details regarding .NET binaries and C# later in the series, so don't sweat the details).
Creating MyLib.dll
To begin, create a file named myLib.cs and author the following C# namespace definition (Listing 3):
Listing 3: Your C#-based .NET code library.
using System;
namespace MyLibrary
{
public class PlatformInfo
{
// Static methods can be called
// directly at the class level.
public static void PrintEnvInfo()
{
// Use System.Environment to show some stats.
string info =
string.Format("\n.NET version is: {0}.",
Environment.Version);
info +=
string.Format("\nSystem Directory is: {0}.",
Environment.SystemDirectory);
info += string.Format
("\nMilliseconds since last boot: {0}.",
Environment.TickCount);
Console.WriteLine("*Your System Information*");
Console.WriteLine(info);
}
}
public class MyMathClass
{
// Non-static members must be called at the
// object level.
public int AddNumbers(int x, int y)
{return x + y;}
public int SubNumbers(int x, int y)
{return x - y;}
public int MultiNumbers(int x, int y)
{return x * y;}
public int DivideNumbers(int x, int y)
{return x / y;}
public string WhichIsBigger(int x, int y)
{
return string.Format("{0} is bigger!",
Math.Max(x, y));
}
}
}
Surprisingly, this trivial namespace definition illustrates a number of aspects of the C# language. First, recall from the previous article that the C# namespace keyword defines a conceptual boundary for a set of related types, while the using keyword allows you to access types contained within another namespace. Here, the MyLibrary namespace defines two class types (in contrast to Java, a single C# source code file may define any number of types, whose names do not need to map to the name of the physical source code file).
The public PlatformInfo class defines a single static method named PrintEnvInfo(). As you most likely already know, static type members can be called directly from the class level without the need to manually create an object in memory. The implementation of this method makes use of the static string.Format() method to build a string containing various bits of information regarding the current development machine. Recall from the previous installment of this series that the curly bracket syntax (e.g. '{0}') signifies a placeholder for dynamic string building (slightly akin to the C printf() function).
The MyMathClass defines a set of instance level methods that manipulate two integer parameter types. As detailed in a future issue, the C# programming language defines a number of keywords which are shorthand notations for true blue types in the System namespace. Here, the C# 'int' keyword represents a System.Int32 structure type. Next notice that the WhichIsBigger() method leverages the static Math.Max() method to return a stylized string. Finally, in the case of each class implementation, notice that C# honors the C, C++, Objective C and Java style escape characters such as '\n'.
Now, at the command line, compile this file into a .NET class library as so (Listing 4):
Listing 4: Compiling a C#-based code library
csc /t:library mylib.cs
Here, we are instructing the C# compiler to generate a class library *.dll file (via /t:library) given an input file named mylib.cs. By default, the name of the *.dll is based on the name of the first input file, thus upon successful compilation, you should have a new .NET assembly named myLib.dll.
Creating myClient.exe
Now that we have a .NET *.dll file, we need to create a client application to make use of it. Given this, create another C# source code file named MyClient.cs which contains the following namespace definition (Listing 5):
Listing 5: The C#-based .NET client application.
using System;
using MyLibrary;
namespace MyClientApp
{
public class MyApp
{
public static void Main()
{
// First show Environment info.
PlatformInfo.PrintEnvInfo();
// Make a MyMathClass type.
MyMathClass m = new MyMathClass();
Console.WriteLine("* Fun with Numbers *");
// Now enter a loop to perform
// simple math.
do
{
int x = 0, y = 0;
Console.WriteLine("Enter two numbers:");
Console.Write("Number 1: ");
x = int.Parse(Console.ReadLine());
Console.Write("Number 2: ");
y = int.Parse(Console.ReadLine());
Console.WriteLine(m.WhichIsBigger(x, y));
Console.WriteLine("{0} + {1} = {2}",
x, y, m.AddNumbers(x, y));
Console.WriteLine("{0} - {1} = {2}",
x, y, m.SubNumbers(x, y));
Console.WriteLine("{0} * {1} = {2}",
x, y, m.MultiNumbers(x, y));
Console.WriteLine("{0} / {1} = {2}",
x, y, m.DivideNumbers(x, y));
Console.Write("Another round? ");
}while("n" != Console.ReadLine());
}
}
}
Again, this simple example proves enlightening. First, given that the client application needs to make use of types located in the System and MyLibrary namespaces, the first lines of code should be clear.
The definition of Main() is important, in that Main() must be static and must have a capital 'M' (as C# is case sensitive). Beyond these restrictions however, the Main() method is quite flexible in that is may (or may not) take an array of strings to represent command line arguments, may (or may not) return an integer to the system, and may be declared public or private. Thus, any of the following Main() methods are a-okay (Listing 6):
Listing 6: The various faces of Main().
public void Main(string[] args) {...}
public void Main() {...}
public int Main() {...}
public int Main(string[] args) {...}
private void Main(string[] args) {...}
private void Main() {...}
private int Main() {...}
private int Main(string[] args) {...}
Here, our Main() method simply invokes the static PlatformInfo.PrintEnvInfo() method and allocates an instance of the MyMathClass type via the C# new keyword. After this point, a do/while loop is entered to prompt the user for two numbers to pass to the various methods of MyMathClass.
Last but not least, notice how the textual data retrieved from System.Console.ReadLine() is transformed into a 'real' numerical value using the static Parse() method of the System.Int32 structure as seen in Listing 7 (remember! The C# 'int' keyword is nothing more than a shorthand notation for declaring a System.Int32 type):
Listing 7: The C# 'int' and System.Int32 relationship.
// 'x' and 'y' are really of type System.Int32!
int x = 0, y = 0;
Console.WriteLine("Enter two numbers:");
Console.Write("Number 1: ");
// System.Int32 defines a static Parse() method.
x = int.Parse(Console.ReadLine());
Console.Write("Number 2: ");
y = int.Parse(Console.ReadLine());
To compile this file into an executable binary requires the following command set (Listing 8):
Listing 8: Building a .C#-based executable.
csc /t:exe /r:myLib.dll MyClient.cs
Here, we are instructing the C# compiler to generate an executable file (via /t:exe) which references types contained within myLib.dll (via /r:myLib.dll) given the input file named MyClient.cs.
Observing the Fruits of your Labor
Unlike a native Macintosh application, you cannot simply double click on MyClient.exe to launch the client binary. When working within the confines of the SSCLI, you need to bootstrap .NET executable assemblies using the CLI Execution utility (clix.exe) as seen in Listing 9:
Listing 9: All good things do come.
clix myclient
Once you have done so, you can manipulate integers to your hearts content (Figure 4).
Figure 4. Your first .NET Application
Wrap Up
So then! At this point you (hopefully) have succeeded in your installation of the SSCLI and the first compilation of your .NET lifestyle. Over the course of this issue, you have been provided with an overview of various subfolders within the /sscli root directory, the use of the HTML-based help system and select command line tools. In the next issue, you will come to know the details of the C# compiler, investigate several of the supplied sample applications and forge ahead with your understanding of C#. Until next month, happy hacking!
Andrew Troelsen is a seasoned .NET developer who has authored numerous books on the topic, including the award winning C# and the .NET Platform. He is employed as a full-time .NET trainer and consultant for Intertech Learning (www.intertechlearning.com) and spends his idle moments at home playing far too many video games. You can contact Andrew at atroelsen@mac.com.
