Introduction To .net

Checklist of Things to check when investigating .NET Products 1. Introduction The .NET technologies can require a number of ancillary products. Those products may not be available as part of the .NET implementation in the Shared Services Infrastructure. This checklist helps to clarify what is required to run .NET products and, in identifying potential incompatibilities. 2. Standard Dependencies for .NET Products Most .NET products will have been built on, tested for, certified for and documented for use on Win32 platforms (usually Windows 2000 or the newer Windows .NET Server). There are a number of standard dependencies that should be verified. • Which version of which operating system has the product been tested for, certified for and documented for? Standard responses would include Windows 2000 Server with Service Pack 3 or Windows .NET Server Release Candidate 2. • Which version of the .NET Framework has the product been tested for, certified for and documented for? Standard responses would include version 1.0 of the .NET Framework Redistributable with Service Pack 2 (for Windows 2000) or the .NET Framework Service Pack 2 for Windows .NET Server Release Candidate 2. • Presuming that the package uses browser-based clients the solution will require a web server. Which version of which web servers has the product been tested for, certified for and documented for? Standard responses would include version 1.0 of the .NET Framework Redistributable with Service Pack 2 (for Windows 2000) or the .NET Framework Service Pack 2 for Windows .NET Server Release Candidate 2.

.NET Overview for Project Managers and Solution Evaluators 1. Introduction The .NET Framework is a new computing platform developed and led by Microsoft that attempts to simplify application development and interoperability in the highly distributed environment of the Internet. The .NET Framework is designed to fulfill the following objectives: • To provide a consistent object-oriented programming environment whether object code is stored and executed locally, executed locally but Internet-distributed, or executed remotely. • To provide a code-execution environment that minimizes software deployment and versioning conflicts. • To provide a code-execution environment that guarantees the safe execution of code, including code created by an unknown or semi-trusted third party. • To provide a code-execution environment that eliminates the performance problems of scripted or interpreted environments. • To make the developer experience consistent across widely varying types of applications specifically including Windows-based applications and Web-based applications. • To build all communication on industry standards to ensure that code based on the .NET Framework can integrate with any other code. 1.1. The Importance of .NET .NET is, first and foremost, Microsoft's implementation of the web services standards. By integrating a supporting framework into their operating systems (Windows 2000, Windows XP and the forthcoming Windows .NET Servers) Microsoft makes it easier to support web services functionality than, for example, an application server that sits on top of the OS. The price for this simplicity - integration - is that web services built for .NET are essentially limited to Microsoft operating systems. Why is .NET important? As the Microsoft implementation of a very important technology the Bank needs to understand how it can and should be used to provide services to employees, partners, customers and prospects. The 'very important technology' - web services - is expected to become a predominant component of applications both developed and purchased. Since Microsoft operating systems power the bulk of the client systems in the Bank and at our partners, prospects and customers it should be well understood to allow us to best benefit from it. 1.2. Audience Project managers and/or solution evaluators intend this document for the use. It is targeted primarily at those who will look to integrate a SSI application with either a bespoke .NET application or one purchased with intent to run on or integrate with the SSI. 2. .NET Description Microsoft .NET is a platform for building, deploying, and running web services and applications. It provides a standards-based, multi-language environment for integrating existing applications with applications and services based on next-generation technologies. In addition, it addresses many of the challenges of deployment and operation of distributed applications. It consists of: • a programming model that enables developers to build web services and applications; • a set of pre-built XML Web services, such as Microsoft .NET My Services (formerly code-named 'Hailstorm'), that helps developers deliver a simple and integrated user experience; • a set of servers, including Windows 2000, SQL Server and BizTalk Server, that integrates, runs, operates and manages XML Web services and applications; • client software, such as Windows XP and Windows CE, that helps developers deliver a rich and consistent user experience across supporting devices; and • tools, such as Visual Studio .NET, to develop XML Web services, native Windows and web-based applications.

3. Introduction to .NET Framework The .NET Framework is the programming model of the .NET platform. It is designed to manage much of the application infrastructure, enabling solution developers to focus on writing the business logic code for their applications. The .NET Framework is comprised of: • the common language runtime (aka, the common language infrastructure or CLI) • a hierarchical set of unified class libraries • a re-architected version of Active Server Pages called ASP.NET The .NET Framework includes native support for XML Web services. XML Web services is the preferred communications vehicle for Some fundamental components of the .NET framework have been submitted and accepted as standards. This has allowed third parties (non-Microsoft) to implement the technologies for non-Microsoft operating systems. The most prominent non-Microsoft implementations are Mono from Ximian, Rotor from Corel and Portable .NET (part of the DotGNU project). Note that all of these are open source projects. 4. Details of .NET Framework 4.1. Common Language Runtime The common language runtime is responsible for run time services such as language integration, security enforcement, memory, process, and thread management. In addition, it has a role at development time when features such as life-cycle management, strong type naming, cross-language exception handling, dynamic binding, and so on, reduce the amount of code that a developer must write to turn business logic into a reusable component. 4.2. Class Libraries Base classes provide standard functionality such as input/output, string manipulation, security management, network communications, thread management, text management, user interface design features, and other functions. The Microsoft ADO.NET data classes support persistent data management and include SQL classes for manipulating persistent data stores through a standard SQL interface. XML classes enable XML data manipulation and XML searching and translations. The Microsoft ASP.NET classes support the development of Web-based applications and XML Web services. The Windows Forms classes support the development of Windows-based smart client applications. Together, the class libraries provide a common, consistent development interface across all languages supported by the .NET Framework. 5. Microsoft's Web services initiatives Microsoft's .NET platform was introduced almost two years ago at their developer conference (PDC), along with their Visual Studio .NET preview release. Currently, the .NET Framework is available for download at... The .NET platform supports the XML Web services architecture, and also incorporates more features and advances (such as ASP+, the new programming language C#, the .NET framework, CLR, and so forth). Note the term "XML" in front of Web services. This was added recently, probably to put an emphasis on XML as the underlying universal language. Microsoft also now offers the SOAP Toolkit, Version 2.0 (gold release) as a download (MSDN). This article does not provide a detailed overview of the .NET platform, and it does not provide a tutorial for Visual Studio .NET. This information is already provided as online documentation bundled with the .NET framework tools, and there are a variety of tutorials, articles and other resources on MSDN and the Web that address this topic. At this time, the ECMA has finished the standardization of the common language infrastructure of the .NET Framework and the C# programming language. Also, a beta version of Microsoft Visual J#™ .NET, a Java compatible language for the .NET platform, is available for download and testing. On the operating system side, Microsoft is working on a .NET server (currently beta 3), which integrates native support for the Web services stack, including UDDI. Microsoft distinguishes between a set of baseline specifications that provide the foundation for application integration and aggregation (XML, SOAP, WSDL, UDDI), and the Global XML Web Services Architecture, a collection of specifications that build on the baseline specifications. IBM and Microsoft co-presented this framework at the W3C Workshop on Web Services in April 2001. A set of technical previews and proposals are available:

• •

WS-Inspection (this can be used for assisting in the inspection of a site for available services). WS-License (this describes how to encode X.509 certificates and Kerberos tickets, as well as arbitrary binary credentials). • WS-Referral (this provides a mechanism to dynamically configure SOAP nodes in a message path to define how they should handle a SOAP message). • WS-Routing (this enables SOAP-based protocol for routing SOAP messages in an asynchronous manner over a variety of transports like TCP, UDP and HTTP). • WS-Security (this describes enhancements to SOAP messaging providing three capabilities: credential exchange, message integrity and message confidentiality). • XLANG (business orchestration language). In addition to these specifications, Microsoft is planning to continue releasing additional specifications in the Global XML Web Services Architecture.

. NET Detailed Guide for Architects, Designers and Senior Developers 1. Introduction The .NET Framework is the programming model of the Microsoft .NET platform for building, deploying and running Web applications, smart client applications and Extensible Markup Language (XML) Web services that expose their functionality programatically over a network using standard protocols such as SOAP, XML, and HTTP. 1.1. The Importance of .NET .NET guidelines are important in understanding the concepts for how .NET services and applications can and should be leveraged in the context of the Shared Services Infrastructure. 1.2. Document Scope This document describes concepts, guidelines and best practices for how .NET managed solutions should be constructed, discovered and used in the Shared Services Infrastructure. The issues discussed pertain to: • Building .NET Services • Discovering and Using .NET Services • Recommend Tools, Tutorials and Other Resources 1.3. Audience This document is intended for the use by anyone developing or integrating solutions for the SSI platform. The intended audience is solution developers (including both component and user interface developers), project managers or anyone involved in the activities of designing and developing solutions to run on the SSI. The document assumes a working knowledge of web-based applications. 2. Building .NET Services 2.1. CLR Fundamentals The .NET Framework provides a run-time environment called the common language runtime, which manages the execution of code and provides services that make the development process easier. The common language runtime (CLR) manages memory, thread execution, code execution, code safety verification, compilation, and other system services. These features are intrinsic to the managed code that runs on the common language runtime. The runtime loads and runs code written in any runtime-aware programming language. Code that targets the runtime is called managed code. Managed code simply means that there is a defined contract of cooperation between natively executing code and the runtime itself. Responsibility for tasks like creating objects, making method calls, and so on is delegated to the runtime, which enables the runtime to provide additional services to the executing code. The runtime features cross-language integration, self-describing components, simple deployment and versioning, and integrated security services. Let's take a quick look at each of these features. 2.1.1. Cross-language integration The runtime makes use of a new common type system capable of expressing the semantics of most modern programming languages. The common type system defines a standard set of types and rules for creating new types. The runtime understands how to create and execute these types. Compilers and interpreters use runtime services to define types, manage objects, and make method calls instead of using tool or language-specific methods. The primary design goal for the type system is to enable deep Multilanguage integration. Code written in one language can now inherit implementation from classes written in another language; exceptions can be thrown from code written in one language and caught in code written in another; and operations such as debugging and profiling

work seamlessly regardless of the languages used to write the code. This means that developers of reusable class libraries no longer need to create versions for each programming language or compiler, and developers using class libraries are no longer limited to libraries developed for the programming language they are using. 2.1.2. Self-describing components Self-describing components, which are now possible on the Microsoft .NET Framework, simplify development and deployment and improve system reliability. Many services provided by the runtime are driven by metadata, information that supplements the executable code. Since all the information is stored together, the executables are referred to as self-describing components. A key advantage of self-describing components is that no other files are needed to use the components. Separate header files are not required for class definitions; the definitions can be obtained from the component itself by inspecting the metadata. Separate IDL files, type libraries, or proxy/stubs are not required to access a component across language or process boundaries; the necessary information is located in the component's metadata. Separate configuration information does not need to be deployed to identify developer requested service attributes. Since the metadata is generated from the source code during the compilation process and stored with the executable code, it is never out of sync with the executable. 2.1.3. Simple deployment and versioning In addition to improvements in deploying individual components, the Microsoft .NET Framework defines an application deployment model that addresses customer issues with the complexities of application installation and DLL versioning (commonly known as "DLL Hell"). Services to support this model are provided by the runtime. The Microsoft .NET Framework introduces the notion of an assembly. An assembly is a group of resources and types, along with metadata about those resources and types, that is deployed as a unit. The metadata is called an assembly manifest and includes information such as a list of types and resources visible outside the assembly. The manifest also includes information about dependencies, such as the version of the assemblies used when the assembly was built. Developers can specify versioning policies to indicate whether the runtime should load the latest version of a dependent assembly installed on the system, a specific version, or the version used at build time. It has always been possible for multiple copies of a software component to reside on the same system. In general, however, only one of these copies can be registered with the operating system or loaded for execution. The policy for locating and loading components is global to the system. The .NET Framework common language runtime adds the infrastructure necessary to support per-application policies that govern the locating and loading of components, which is generally referred to as side-by-side deployment. Assemblies can be private to an application or shared by multiple applications. Multiple versions of an assembly can be deployed on a machine at the same time. Application configuration information defines where to look for assemblies, thus the runtime can load different versions of the same assembly for two different applications that are running concurrently. This eliminates issues that arise from incompatibilities between component versions, improving overall system stability. If necessary, administrators can add configuration information, such as a different versioning policy, to assemblies at deployment time, but the original information provided at build time is never lost. Because assemblies are self-describing, no explicit registration with the operating system is required. Application deployment can be as simple as copying files to a directory tree. (Things are slightly more complicated if unmanaged components must be installed for the application to work.) Configuration information is stored in XML files that can be edited by any text editor. 2.1.4. Integrated security services Finally, the runtime also supplies integrated, pervasive security services to ensure that unauthorized users cannot access resources on a machine and that code cannot perform unauthorized actions. This improves overall system safety and reliability. Since the runtime is used to load code, create objects, and make method calls, the runtime can perform security checks and enforce security policy as managed code is loaded and executed. The Microsoft .NET Framework provides both code access security and role-based security. With code access security, developers can specify the required permissions their code needs to accomplish work. For example, code may need permission to write a file or access environment variables. This information is stored at the assembly

level, along with information about the identity of the code. At load time and on method calls, the runtime verifies that the code can be granted the permissions it has asked for. If not, a security violation is reported. Policies for granting permissions, known as trust policies, are established by system administrators, and are based on evidence about the code such as who published the code and where it was obtained from, as well as the identity and requested permissions found in the assembly. Developers can also specify permissions they explicitly don't want, to prevent malicious use of their code by others. Programmatic security checks can be written if the permissions required depend on information that isn't known until runtime. In addition to code access security, the runtime supports role-based security. Role-based security builds on the same permissions model as code access security, except that the permissions are based on user identity rather than code identity. Roles represent categories of users and can be defined at development or deployment time. Policies for granting permissions are assigned to each defined role. At runtime, the identity of the user on whose behalf the code is running is determined. The runtime determines what roles the user is a member of and then grants permissions based on those roles. 2.2. Building applications that support CLR When building applications or re-usable types (components) for the .NET Framework, you must first select a CLRbased programming language that you intend to write your source code in. The .NET Framework supports several programming languages including C#, J#, C++ with Managed Extensions, Visual Basic .NET, Cobol, Perl and many more. The language you choose will determine how you express your intentions to the .NET Framework. Once you've written your source code, you run it through the corresponding language compiler and the compiler produces an assembly file. An assembly file contains Microsoft Intermediate Language (MSIL) and metadata. Normally, compilers produce binary CPU instructions specific to the CPU you intend to you run your code on. However, MSIL is an intermediate language that is CPU- independent. That is, at runtime the CLR compiles the MSIL code into native CPU code. If you are running the application on a Pentium machine, then the CLR produces native x86 code. If you are running the application on an Itanium machine, then the CLR produces native IA64 code. In addition to the MSIL, the assembly file also contains metadata. Metadata is a set of tables that are embedded in the assembly file. These tables are produced by the compiler and contain a great deal of information about the application. For example, metadata has tables that describe all of the types, methods, and fields that were defined by the application's source code. In addition, metadata also includes tables that describe all of the types, methods, and fields that are referenced by methods in the application's source code. Metadata is very complete and is always embedded in the assembly file ensuring that the metadata and the MSIL it describes are always in sync with one another. 2.3. .NET Services Framework On top of the common language runtime is the services framework. This framework provides a collection (called the .NET Framework class library) of reusable types that tightly integrate with the common language runtime. All classes within the collection comply with a set of naming and design guidelines to further reduce the learning curve for developers. In addition, The class library is object oriented, providing types from which your own managed code can derive functionality. This not only makes the .NET Framework types easy to use, but also reduces the time associated with learning new features of the .NET Framework. In addition, third-party components can integrate with classes in the .NET Framework. The framework includes a base set of class libraries that developers would expect in a standard language library, such as collections, input/output, string, and numerical classes. In addition, the base class library provides classes to access operating system services such as graphics, networking, threading, globalization, and cryptography. The framework types enable the developer to accomplish a range of common programming tasks, including tasks such as string management, data collection, database connectivity, and file access. The services framework also includes a data access class library, as well as classes that development tools can use, such as debugging and profiling services. In addition to these common tasks, the class library includes types that support a variety of specialized development scenarios. For example, you can use the .NET Framework to develop the following types of applications and services: • Console applications. • Scripted or hosted applications.

• • • •

Windows GUI applications (Windows Forms). ASP.NET applications. XML Web services. Windows services.

2.4. Class Library Namespaces The .NET Framework class library is a library of classes, interfaces, and value types that are included in the Microsoft .NET Framework SDK. This library provides access to system functionality and is designed to be the foundation on which .NET Framework applications, components, and controls are built. The System namespace contains fundamental classes and base classes that define commonly used value and reference data types, events and event handlers, interfaces, attributes, and processing exceptions. Other classes provide services supporting data type conversion, method parameter manipulation, mathematics, remote and local program invocation, application environment management, and supervision of managed and unmanaged applications. You can view the complete list of public classes included in the .NET framework SDK here. 2.5. XML Web Services One of today's most pressing challenges for the Bank, is application reuse, interoperability and integration; taking different applications running on different operating systems built with different object models using different programming languages and turning them into functional services. The Shared Services Infrastructure's vision is to address this challenge via Web Services (or XML Web Services), which is a set of technologies based on an open set of standards such as HTTP, XML, SOAP, WSDL, UDDI, etc. Both J2EE and the .NET Framework provide open implementations of Web Services in addition to an environment to create, deploy, secure, scale and maintain these services. 2.5.1. Understanding XML Web Services Broadly speaking, a Web Service is simply an application delivered as a service that can be integrated with other Web Services using Internet standards. In other words, it's an URL-addressable resource that programmatically returns information to clients who want to use it. One important feature of Web Services is that clients don't need to know how a service is implemented. In this section, I'll explain how Web Services combine the best aspects of component-based technologies and the Web, and introduce the infrastructure needed to communicate with Web Services. Like components, Web Services represent black-box functionality that can be reused without worrying about how the service is implemented. Web Services provide well-defined interfaces, called contracts that describe the services provided. Developers can assemble applications using a combination of remote services, local services, and custom code. Unlike current component technologies, however, Web Services do not use object model-specific protocols such as DCOM, RMI, or IIOP that require specific, homogeneous infrastructures on both the client and service machines. While these tightly coupled component technologies may be acceptable within a controlled environment, they become impractical for heterogeneous environments. As the set of participants in an integrated business process changes, and as technology changes over time, it becomes very difficult to guarantee a single, unified infrastructure among all participants. Web Services take a different approach; they communicate using ubiquitous Web protocols and data formats such as HTTP and XML. Any system supporting these Web standards will be able to support Web Services. Furthermore, a Web Service contract describes the services provided in terms of the messages the Web Service accepts and generates rather than how the service is implemented. By focusing solely on messages, the Web Services model is completely language, platform, and object model-agnostic. A Web Service can be implemented using the full feature set of any programming language, object model, and platform. A Web Service can be consumed by applications implemented in any language for any platform. As long as the contract that explains the service's capabilities and the message sequences and protocols it expects is honored, the implementations of Web Services and Web Service consumers can vary independently without affecting the application at the other end of the conversation.

The minimum infrastructure required by the Web Services model is purposefully low to help ensure that Web Services can be implemented on and accessed from any platform using any technology and programming language. The key to Web Service interoperability is reliance solely on Web standards. However, simply agreeing that Web Services should be accessed through standard Web protocols is not sufficient to make it easy for applications to use Web Services. Web Services become easy to use when a Web Service and Web Service consumer rely on standard ways to represent data and commands, to represent Web Service contracts, and to figure out the capabilities a Web Service provides. XML is the obvious choice for defining a standard yet extensible language to represent commands and typed data. While rules for representing commands and typed data using other techniques (such as encoding as a query string) could be defined, XML is specifically designed as a standard metalanguage for describing data. The Simple Object Access Protocol (SOAP) is an industry standard for using XML to represent data and commands in an extensible way. A Web Service can choose to use SOAP to specify its message formats. 2.5.2. XML Web Services Fundamentals There is some debate over the exact definition of Web services. At a minimum, however, a Web service is any piece of software that makes itself available over the Internet and uses a standardized XML messaging system. XML is used to encode all communications to a Web service. For example, a client invokes a Web service by sending an XML message, then waits for a corresponding XML response. Because all communication is in XML, Web services are not tied to any one operating system or programming language. For instance, Java can talk with Perl; Windows applications can talk with Unix applications. Beyond this basic definition, a Web service may also have two additional (and potentially desirable) properties: • First, a Web service can have a public interface, defined in a common XML grammar or schema (XSD). The interface describes all the methods available to clients and specifies the signature for each method. Currently, interface definition is accomplished via the Web Service Description Language (WSDL). • Second, if you create a Web service, there should be some relatively simple mechanism for you to publish this fact. Likewise, there should be some simple mechanism for interested parties to locate the service and locate its public interface. The most prominent directory of Web services is currently available via UDDI, or Universal Description, Discovery, and Integration. 2.5.2.1. XML Schema Definition (XSD) XML Schema is a W3C Recommendation (a standard) as of May 2, 2001. The XML Schema definition language (XSD) enables you to define the structure and data types for XML documents. An XML Schema defines the elements, attributes, and data types that conform to the World Wide Web Consortium (W3C) XML Schema Part 1: Structures Recommendation for the XML Schema Definition Language. The W3C XML Schema Part 2: Datatypes Recommendation is the recommendation for defining data types used in XML schemas. 2.5.2.2. Web Services Description Language (WSDL) The Web Services Description Language (WSDL) currently represents the service description layer within the Web service protocol stack. WSDL defines an XML-based grammar for describing network services as a set of endpoints that accept messages containing either document-oriented or procedure-oriented information. The operations and messages are described abstractly. They are bound to a concrete network protocol and message format to define an endpoint. Related concrete endpoints are combined into abstract endpoints (services). WSDL is extensible to allow the description of endpoints and their messages regardless of what message formats or network protocols are being used to communicate. 2.5.2.3. Simple Object Access Protocol (SOAP) SOAP is a lightweight and simple XML-based protocol that is designed to exchange structured and typed information on the Web. The purpose of SOAP is to enable rich and automated Web services based on a shared and open Web infrastructure. SOAP can be used in combination with a variety of existing Internet protocols and formats including HTTP, SMTP, and MIME and can support a wide range of applications from messaging systems to RPC. 2.5.2.4. Universal (SOAP) UDDI (Universal Description, Discovery, and Integration) currently represents the discovery layer within the Web services protocol stack. The UDDI specification defines a SOAP-based Web service for locating Web services and programmable resources on a network. UDDI provides a foundation for developers and administrators to readily share information about internal services across the enterprise and public services on the Internet.

2.5.3. Implementing XML Web Services in .NET .NET natively supports XML Web Services. In other words, .NET provides the infrastructure and building blocks, which greatly simplify development and deployment efforts, associated with XML Web Services. The .NET framework core libraries includes the Sytem.Web.Services namespace, which component developers may use to add web services functionality to their application.

Overview of non-Win32 Implementations of .NET Foundations 1. Introduction While .NET (platform / framework) originated as a commercial effort by Microsoft as it's next-generation Win32 technology, the framework is garnering interest in the non-Microsoft development community. Some of the reasons include: • The framework is largely based on industry standards. • The framework promotes a well-defined, hierarchical set of APIs. • The framework promotes contract/interface-based programming. • The framework has support for multiple languages. • The framework has native support for web services. Based on the above, .NET has caught the attention of the Open Source community and efforts are underway to create non-Win32 implementations of the .NET foundations (core runtime, class libraries, etc.) - primarily targeted at the Lintel platform. This document will describe the most popular implementations and describe why this is relevant to the Shared Services Infrastructure (SSI). 1.1. The Importance of this Document It is expected that there will be an increasing need at the Bank to support web-based applications and web services that are based on .NET (typically third party). As the SSI is composed of both Linux and Win2K servers we need to understand the viability of hosting .NET applications in a mixed (Linux and Win2k) environment. 1.2. Document Scope This document describes non-Win32 implementations of the .NET framework foundations. This document provides an overview of these implementations and assumes the reader has a basic knowledge of the .NET framework. 1.3. Audience This document is intended for use by anyone developing or integrating solutions for the SSI platform. The intended audience is solution developers (including both component and user interface developers), project managers or anyone involved in the activities of designing and developing solutions to run on the SSI. The document assumes a working knowledge of web-based applications. 2. Relevance of non-Win32 Implementations to the SSI The are two reasons why non-Win32 implementations are relevant to the Shared Services Infrastructure: 1. Adherence to Huron recommended standards. 2. Provide flexibility in the choice of platforms and, as a result, avoid vendor lock-in. The Shared Services Infrastructure currently supports Win32-based servers (Windows 2000 Server). In the near future it is planned to add Linux-based servers to the platform. While Java (specifically J2EE) is the preferred application environment - in part because it is by nature cross-platform - .NET is a vendor-sponsored initiative that will have sufficient market penetration to merit support. Thus we need to understand the implications of running .NET-based technology solutions on non-Win32 platforms with an emphasis on Linux on Intel (Lintel). 3. Current non-Win32 Implementations of .NET There are currently three significant efforts underway to create non-Win32 implementations of the .NET foundations. Each have somewhat different goals in mind and are discussed in greater detail in the following sections. The three implementations are: • Mono, • DotGNU and

• Rotor. 4. Mono The Mono Project is an initiative sponsored by Ximian. It is, at its core, an open source Linux version of the Microsoft .NET development platform. Its objective is to enable Linux developers to build and deploy crossplatform applications that include .NET technologies. The project will implement various pieces of the .NET puzzle that Microsoft have now submitted to either the European Computer Manufacturers Association (ECMA), Institute of Electrical and Electronics Engineers (IEEE) or the World-Wide Web Consortium (W3C) for standardization. Mono is an implementation of the development framework only. This means that it while it implements features including the common language runtime (CLR) and C# compiler it does not provide ancillary services such as Passport or software-as-a-service. Mono includes a compiler for the C #language, a runtime for the Common Language Infrastructure (also referred as the CLR) and a set of class libraries. The runtime can be embedded in your application. Mono has implementations of both ADO.NET and ASP.NET as part of its distribution. The various pieces that will make up Mono include: • A C# compiler. • The Virtual Execution System that will have the Just-in-Time compiler, garbage collector, loader, threading engine. • A byte code interpreter will be provided for quickly porting Mono to new systems and for debugging during the development process. It is not intended to be the ideal execution environment. • An implementation of the .NET class library. • Visual development tools. • A CIL GCC front-end. 4.1. Mono and GNOME GNOME is an umbrella project that consists of infrastructural components (GUI toolkit, XML libraries, CORBA implementation, printing architecture, imaging system), a desktop environment, and productivity applications. The GNOME infrastructural components can be used to quickly implement various pieces of Mono's .NET class libraries without reinventing the wheel. All these components are licensed under the terms of the GNU LGPL. Libart will be used to implement the Drawing.2D API; Gtk+ and the GNOME libraries will be used to implement the WinForms API and Glib and libxml will be used in various places. 4.2. Current Plans and Status for Mono (January 2003) Taking advantage of the standards, Mono developers have pledged to release sometime this year the "Mono Core," which will mimic the .Net Framework for Linux and UNIX operating systems. However, even Mono members admit that there is still much work to be done before the first version of Mono is released. Mono developers have yet to recreate the Windows Forms, Ximian said. The group has, however, completed a JIT (just-in-time) run-time engine, and a C# compiler that is self-hosting, which means it can automatically compile an application written in C# to run on Linux or UNIX systems. 5. DotGNU DotGNU is a Free Software project to create a platform for webservices that can be written in a variety of different programming languages including Java and C#. The main objectives of DotGNU are to build a webservices platform and a Virtual Identities system. 5.1. DotGNU and GNU GNU is the umbrella project for DotGNU, which itself is a meta-project that will consist of several other software development projects.

5.2. DotGNU Software Development Projects There are two main tracks of development of DotGNU, each of which can have any number of DotGNU projects. These tracks are: • DotGNU Platform • DotGNU Virtual Identities 5.2.1. DotGNU Platform The DotGNU Platform is a loosely arranged set of components designed for the execution of webservices. At the time of this writing it consists of the following major components: • DotGNU Portable.NET The goal of this DotGNU Portable.NET is to provide a runtime engine, core library and suite of free software tools to build and execute .NET applications, including a C# compiler, assembler, disassembler. The initial target platform is GNU/Linux, with other platforms to follow in the future. DotGNU Portable.NET is focused on compatibility with the ECMA specifications for CLI. There are other projects under the DotGNU meta-project to build other necessary pieces of infrastructure, and to explore non-CLI approaches to virtual machine implementation. • Support for Java bytecode As an alternative to C# and CLR, DotGNU hopes to support Java and other languages that can be compiled to Java bytecode. Plans are in the works to create a JVM implementation for the DotGNU Platform. • DotGNU Secure Execution Environment Portable Executables that come in one of the multiple bytecode formats supported by the DotGNU platform will be executed in a DotGNU Secure Execution Environment (SEE). In order to facilitate remote execution, this will probably be implemented as a daemon, and there is code for a test daemon called Andromeda, which demonstrated how plugins could be bound to the daemon. • DotGNU Distributed Execution Environment DotGNU's Distributed Execution Environment will be like an operating system for a "distributed computer" consisting of several instances of the "DotGNU Secure Execution Environment" that are running on several computers. This system must be able to take care of replicating databases across all the parts of this "distributed computer" and propagating updates. 5.2.2. DotGNU Virtual Identities This will be a totally decentralized authentication / personal information system that can compete with Microsoft's "Passport" system. This system will eventually implemented as an application that runs on the DotGNU platform. Unlike other applications it makes sense to develop this application under the umbrella of the DotGNU meta-project, because authentication is also an essential component of every operating system. 5.3. Current Plans and Status for DotGNU (January 2003) DotGNU is beginning it's third year of maturation. Many of the original plans have been replaced along with new projects being added. One of the continuing problems is the lack of developers. The other big problem is lack of code. For the architecture projects the ground work of specification writing had to be accomplished first before any code could be written, luckily the specs are in the final phase and coding work is expected to begin soon. Despite these problems the Portable.NET project reached it's most important milestone, the compiler can now compile the baselib removing dependency on the Microsoft C# compiler. In the fall of 2002 the organization of DotGNU was reorganized. Working Groups were created to support cooperation between similar projects. The leaders of all the Working Groups come together in the DotGNU Working Group, which effectively acts like a cabinet for DotGNU. The role of the Steering Committee was scaled down a bit to that of high court. The SC still acts as the highest power in DotGNU, but it doesn't set out the course anymore.

Last but not least the focus of DotGNU is beginning to shift from providing as much compatibility with .NET as possible to building a webservice supporting system which is only compatible with .NET where absolutely needed. The DotGNU system will be a bridge which applications can use to communicate with other applications regardless of where those applications run, in what language they are written, etc. 6. Rotor Microsoft teamed with Corel to build a shared source implementation of the C# programming language and common language infrastructure (CLI) specifications. The project, code named "Rotor", has successfully released a beta version of the Shared Source CLI. The Shared Source CLI consists of the following features: • An implementation of the runtime for the Common Language Infrastructure (ECMA-335) that builds and runs on Windows XP and FreeBSD. • Compilers that work with the Shared Source CLI for C# (ECMA-334) and JScript • Development tools for working with the Shared Source CLI such as assembler/disassemblers (ilasm, ildasm), a debugger (cordbg), metadata introspection (metainfo), and many other utilities. • The Platform Adaptation Layer (PAL) used to port the Shared Source CLI from Windows XP to FreeBSD • The build environment tools (nmake, build, and others) • Complete documentation for the implementation. • Test suites used to verify the implementation. Recently, a Linux port of Rotor was made available and has passed 94% of its tests. See Rotor for Linux. 7. Conclusion While each of the non-Win32 implementations are not as feature-rich as their Microsoft conterpart it is within reason to expect a modest level of cross-platform support for .NET with these frameworks. The level of support is likely to be sufficient for most scenarios. Of the three development frameworks (Mono, DotGnu and Rotor) Mono is considered the best fit for the Shared Services Infrastructure, as it offers the widest support for both Linux and Windows and is expected to provide full support for the .NET core libraries. When extending .NET applications which are expected to run within the SSI it is important that a single development framework and language be adopted as a standard for future development. It is our recommendation that these extensions be written using the Mono development framework and that the choice of development language be C#.