Some interesting new features in the SSCLI 2.0 release include:
The Microsoft® Shared Source CLI 2.0 is a working implementation of the ECMA-334 and ECMA-335 standards (known to us mortals as the Common Language Infrastructure and the C# programming language). The source code in this distribution builds Microsoft® Windows only, support for further platforms is planned. Besides the CLI and the C# compiler, this distribution contains a JScript compiler written entirely in C#, as well as a wide variety of tools, utilities, managed classes, and samples. It is intended to be an appealing new platform alternative for people who want to learn, to teach, to tinker, or to experiment more formally with computer languages and computer language infrastructure.
This is the forth release of the Shared Source CLI, and the first release for the
2.0 implementation of the runtime and framework. You can find older versions of
the SSCLI at http://msdn.microsoft.com/net/sscli/. It is for
non-commercial, experimental use only. The distribution is completely unsupported, although the
development team will be checking in on the
microsoft.public.shared_source.cli newsgroup.
The Shared Source CLI 2.0 is being distributed as source code under a Shared Source license. It is important for you to read through the brief license that is included with your copy of this distribution now, because once you examine the code or use it in any way, you will be bound by the terms of this license. For more information about the Shared Source program at Microsoft, take a look at the Microsoft Shared Source Initiative Web page at http://www.microsoft.com/resources/sharedsource/default.mspx or search www.microsoft.com for "Shared Source".
By default, the build scripts in this distribution produce an optimized debug build of the tools and runtime. This is because we believe that most of you are programmers, and that you will want to be spelunking around in the debugger but you still want reasonable execution performance. If you want maximum source debugging support you should choose a checked build which will turn off optimizations and allow better source-level debugging. If you want to get more performance, you can build a free build, which will execute code considerably faster. For instructions, see the detailed build instructions in building_sscli.html.
Colloquially, we refer to this project as Rotor, and this 2.0 release as Rotor Whidbey. Why? Well, you'll find the following definitions for the word Rotor:
It's obvious! Rotor is all of these and more...
Please read the license before you begin.
OK, having taken care of that, Rotor has been built and tested on Windows XP only. If you want to build and run the source code, you'll need some additional software. The Rotor build process uses Perl in several ways, both to run the test harness and as a way to autogenerate some utility code. You will need Microsoft Visual Studio® 2005 as well as Perl. (The Rotor development team currently uses ActivePerl 5.8.7.813, from ActiveState, but perl.org is always a good bet as well.)
As far as hardware goes, we really recommend having 512M of memory in your computer. While we've heard of success in building on machines with less, it can be mighty slow (and the swap thrashing can be horrific). As far as disk space goes, 100 megabytes should be sufficient if all you will be doing is viewing the source, but if you are doing active development (especially running the test suites) you will need at least a gigabyte of free disk space.
Please note that the Rotor distribution was only tested on operating systems using English locales.
Windows
For more information you might want to peruse the documentation index for more links into the documentation set. We recommend that you also have either Visual Studio 2005 or the .NET Frameworks SDK as secondary documentation to the ECMA specifications.
We've included a detailed document about building Rotor, but if you are impatient, here are very brief instructions to get you up and running quickly.
On Windows: Once you have extracted the contents of the
tarball using your favorite archiving utility, open a command window and run the
env.bat script from the sscli20 (root) directory of the distribution.
You need to run the script from this directory because it uses the current
directory to set up subsequent environment variables. After this, in the
same window, type buildall, which will initiate the build process.
In order to be useful on multiple platforms and systems, text files in the archive are
linefeed terminated. If you are running Windows, you'll want to view these
files in an editor that handles this case automatically (many do, including
WordPad and the Visual Studio editor), or else use a utility program to remove
the convert the linefeeds to Windows-style carriage-return/linefeed termination.
Once the build has successfully finished, you should be able to compile and execute the simple "hello world" test program by changing to the samples\hello directory (samples/hello on UNIX systems based platforms), and then typing:
csc hello.cs clix hello.exe
This will churn for a while (loading takes less time on the free build), and then print out "Hello World!" The program clix is a program loader for managed executables. The first line uses the C# compiler to produce hello.exe from hello.cs, a tiny program that prints "Hello World!" to the system console.
Assuming that hello.exe works, you are now able to compile C# sources using csc (the C# compiler), and JScript sources using the jsc compiler. Remember to always run Rotor 2.0 programs in a shell that has been set up using the env scripts as described above. Also remember that managed executables need to be launched using clix in order to run under Rotor. For example, the JScript compiler must be run in this way.
You are almost certain to find that the map of the source code to very useful in navigating around the distribution. The document on building rotor will also be very helpful if you are modifying code; its scenario-based descriptions can be time-saving.
Rotor comes with a number of test suites covering various aspects of its implementation:
For more information refer to the testing_overview.html document in the sscli/docs directory.
The Shared Source CLI runtime is not intended for use as a secure environment, although its source code does provide a very good example of how a secure execution environment might be built. By default, strongname verification is turned off for several important public keys - see the release notes for details as to how strongnames work in this distribution.
The implementation of Rotor's global assembly cache and strongname verification system is completely separate from the implementation used by the commercial Microsoft .NET Framework, and because of this, there should be no interaction between the two. Turning off verification in Rotor will not impact the Microsoft .NET Framework on Windows in any way.
There are a small number of files in this distribution that carry their own licenses which are compatible with the Microsoft Shared Source CLI, C#, and JScript License. Anyone building modified versions of this code should be aware of and comply with these license terms.
To prevent repetativeness (and less typing on the authors behalf), we have used the word SSCLI to mean SSCLI 2.0 throughout the documentation. SSCLI v1 will be used to make explicit reference to the original release of Rotor, the SSCLI Version 1.0.
Copyright (c) 2006 Microsoft Corporation. All rights reserved.