Overview of the Microsoft .NET Framework

1. Overview of the Microsoft .NET Framework Jim Fiddelke, Greenbrier & Russel

2. Agenda • Overview • The CLR • The Framework Class Library • ASP.NET • Web Forms • Web Services • Data Access • WinForms • Questions and Answers

3. Overview

4. What is .NET • Three main elements: • The Framework (CLR, FCL, ASP, WinForms) • The Products (Windows, Visual Studio, Office) • The Services (My Services) • Development began in 1998. • Framework Goals: • Improved reliability and integrated security. • Simplified development and deployment. • Unified API, multi-language support. • New version of COM? • XML is the .NET “Meta-Language”. • All MS server products eventually .NET-enabled.

5. The .NET Framework ASP.NET Windows Forms Web Services Web Forms Controls Drawing ASP.NET Application Services Windows Application Services Framework Class Library ADO.NET XML Threading IO Network Security Diagnostics Etc. Common Language Runtime Common Type System Lifecycle Monitoring Memory Management

6. The .NET Framework • Beta 1 released Oct, 2000. • Beta 2 released July, 2001. • Finalized in Dec, shipping in Feb 2002. • SDK and Visual Studio.NET (includes SDK) run on Windows NT 4.0, 2000, and XP. • Redistribution Pack (runtime) runs on Windows 98, NT 4.0, 2000, ME, and XP. • Framework will ship with Windows .NET Server (mid-2002) and beyond.

7. The New Languages - C# and VB.NET • Performance differences very minor. • VB.NET introduces long sought-after features: • Inheritance • Parameterized Class Constructors • Function Overloading • Multi-Threading • Structured Error Handling • Creating NT Services • VB.NET not backward compatible with VB6. • VB6 will be supported until the third release of VB.NET (5-6 years away). • C# • New modern, object-oriented language • Similar to C++/Java • “High-Fidelity” language of .NET

8. What About Java? • Microsoft is developing “JUMP” (Java User Migration Path to .NET). A set of conversion tools. • Late-Breaking News: Visual Studio.NET will include a Java component called Visual Java.NET (or maybe Visual J# .NET).

9. .NET vs. J2EE • Both are similar in many ways: • Server- and client-side model for building enterprise applications. • Virtual machine designed to inspect, load, and execute programs in a controlled environment. • APIs for creating both fat- and thin-client models. • APIs for foundation services (data access, directory, remote object calls, sockets, forms). • Development environment for dynamic web pages. • J2EE: “Language-Dependent & Platform-Independent”. • .NET: “Language-Independent & Platform Dependent”.

10. Java VM Java VM Java VM J2EE: Language-Specific, Platform- Independent Person.java Linux Java VM Person bytecodes Deploy Windows Company bytecodes Address bytecodes Solaris Address.java Company.java

11. CLR CLR CLR .NET: Language-Independent, Platform- Specific Person.vb Windows (Visual Basic) CLR Person MSIL Deploy Windows Company MSIL Address MSIL Windows Address.cs (C#) Company.cbl (Cobol)

12. J2EE • The core (JVM and standard class libraries) are mature. • 2 million Java programmers. • J2EE implementations are not entirely cross-platform. • Java’s true potential is realized only when all (or most) development is done in Java. • Changing the Java language specification has an enormous impact on the entire platform.

13. .NET • Being newer, .NET adds improvements such as native XML support. • 6 million VB developers. • All development and deployment is Windows.

14. The CLR

15. What is the CLR • The CLR is at the core of the .NET platform - the execution engine. • A “Managed Execution Environment”. Manages the execution of code and provides services that make development easier. • Code developed for a compiler that targets this platform is referred to as “Managed Code”. • Code that relies on COM and the Win32 API is “Un-Managed Code”. • VB6 is 100% “Un-Managed”, VB.NET is 100% “Managed”.

16. Key Features and Benefits • Cross-Language Integration • Cross-Language Inheritance • Cross-Language Exception Handling • Enhanced Security • Versioning and Deployment Support • Debugging and Profiling Services • Automatic Memory Allocation and Management • A Common Type System • Object Lifecycle Monitoring and Garbage Collection

17. Key Features and Benefits • Key objective is to handle much of the “programming infrastructure”, such as memory management and object proxies. Much is replaced by metadata. • Memory management is self-configuring and self-tuning. • Many common bugs should be eliminated (such as memory leaks). • Tool support - designed to work well with designers, wizards, debuggers, etc. • CLR replaces the existing runtime layers of COM, MTS, COM+.

18. Key Features and Benefits • Language interoperability is built into the Framework by means of a Common Type system. • There is a CLR-to-COM interoperability layer. • Better debuggers - can jump between source across different languages. • Simplified deployment - no more “DLL Hell”. CLR supports “side-by-side” execution - the ability to load and execute multiple versions of the same assembly.

19. Key Features and Benefits COM provides a way for components to integrate. However, each component must provide the “plumbing” and objects cannot directly interact.

20. Key Features and Benefits CLR With the .NET CLR, components are built on a common substrate. No “plumbing” is needed and objects can directly interact.

21. Application Types • The CLR supports the following types of applications: • Console • Windows Forms • Web Forms • Web Services • Service Control Manager Services (NT Services) • Tools and Utilities • Components

22. The Common Language Specification • CLR works with multiple languages - including those developed by third parties (approx. 22). • Each language compiler may support different subsets of the runtime’s functionality. • The Common Language Specification (CLS) defines the requirements for a .NET component to be completely usable by other .NET applications. • The CLS spec. defines a subset of the CLR types and features. • The Framework Class Library (FCL) itself is fully-compliant with the CLS. • VB.NET is fully CLS compliant. • C# is not - you can create C# components that expose types not usable by VB.NET. • There is a compiler directive to force CLS-compliance.

23. MSIL and JIT Compilation • Source code is compiled into MSIL (Microsoft Intermediate Language). Similar to Java bytecodes - CPU-independent instructions. • MSIL allows for runtime type-safety and security, as well as portable execution platforms (all Windows). MSIL code cannot play tricks with pointers or illegal type conversions. • The MSIL architecture results in apps that run in one address space - thus much less OS overhead. • Compilers also produce “metadata”: • Definitions of each type in your code. • Signatures of each type’s members. • Members that your code references. • Other runtime data for the CLR.

24. MSIL and JIT Compilation • Metadata in the load file along with the MSIL enables code to be self-describing - no need for separate type libraries, IDL, or registry entries. • When code is executed by the CLR, a JIT compilation step occurs. Code is compiled method-by-method to native machine code.

25. Garbage Collection • COM manages object lifetimes through reference counting. Circular references were a big problem. • CLR manages objects through a process of garbage collection. CLR will detect and break down circular references. • COM has “deterministic finalization” - you know that when you release the last reference to an object, that object goes away, and can code accordingly. • CLR has “non-deterministic finalization”.

26. Metadata • Metadata is generated by the compiler and stored in the executable (EXE or DLL). • Similar to a COM type library - contains information that describes the component’s public types (enums, structures, interfaces, and classes). • IDL no longer used. • No need to define an interface to program against a class. • Interface-based programming still alive and well in .NET. • Metadata includes: • Assembly - name, version, culture, public key, exported types, security permissions. • Base classes and interfaces.

27. Packaging: Modules, Types, Assemblies, and the Manifest • A “module” refers to a managed binary, such as an EXE or DLL. • Modules contain definitions of managed types, such as classes, interfaces, structures, and enumerations. • An assembly can be defined as one or more modules that make up a unit of functionality. Assemblies also can “contain” other files that make up an application, such as bitmaps and resource files. • An assembly is not a physical file. • An assembly is the the fundamental unit of deployment, version control, activation scoping, and security permissions.

28. Packaging: Modules, Types, Assemblies, and the Manifest • An assembly is a set of boundaries: • A security boundary - the unit to which permissions are requested and granted. • A type boundary - the scope of an assembly uniquely qualifies the types contained within. • A reference scope boundary - specifies the types that are exposed outside the assembly. • A version boundary - all types in an assembly are versioned together as a unit.

29. Packaging: Modules, Types, Assemblies, and the Manifest • An assembly contains a “manifest”, which is a catalog of component metadata containing: • Assembly name. • Version (major, minor, revision, build). • Assembly file list - all files “contained” in the assembly. • Type references - mapping the managed types included in the assembly with the files that contain them. • Scope - private or shared. • Referenced assemblies. • In many cases, an assembly consists of a single EXE or DLL - containing the module’s MSIL, the component metadata, and the assembly manifest. In other cases, the assembly may consist of many DLLs, with the manifest in it’s own file. • No MSIL code can ever be executed unless there is a manifest associated with it.

30. Packaging: Modules, Types, Assemblies, and the Manifest • Two types of assemblies: • Private - Usually deployed in the same directory as the client application and used only by a single application. • Shared - Used by any application and usually installed in a special Global Assembly Cache. • Version information from a dependent assembly is recorded in a client manifest.

31. Packaging: Modules, Types, Assemblies, and the Manifest Assembly Manifest Module Metadata MSIL Type Type Type

32. The Common Type System • At the core of the Framework is a universal type system called the .NET Common Type System (CTS). • Everything is an object - but efficient. • It is this CTS that make cross-language inheritance possible. • All types fall into two categories - Value types and Reference types. • Value types contain actual data (cannot be null). Stored on the stack. Always initialized. • Three kinds of value types: Primitives, structures, and enumerations. • Language compilers map keywords to the primitive types. For example, a C# “long” is mapped to System.Int32.

33. The Common Type System • Reference types are type-safe object pointers. Allocated in the “managed heap”. • Four kinds of reference types: Classes, arrays, delegates, and interfaces. • When instances of value types go out of scope, they are instantly destroyed and memory is reclaimed. • When instances of reference types go out of scope, they are garbage collected. • Boxing = converting an instance of a value type to a reference type. Usually done implicitly through parameter passing or variable assignments. • UnBoxing = casting a reference type back into a value type variable.

34. The Common Type System Object String Array ValueType Exception Delegate Class1 Primitive Types Enum Multicast Delegate Class2 Int16 Boolean Class3 Int32 Byte Int64 Char Single Currency Double DateTime Decimal TimeSpan

35. Attributes • Attributes in the CLR allow you to add additional information to the classes you create. This information is read by using the System.Reflection classes defined in the Framework Class Library. • One particular example of using attributes is the “[WebMethod]” attribute used to expose a Web Service method.

36. Error Handling • Error handling in the CLR is structured and consistent. • Uses the “Try…Catch…Finally” pattern. • “Throw” enables you to raise an exception.

37. Delegates • A new concept that is central to the programming model of the CLR. • Delegates are like function pointers, but are actually type-safe, secure, managed CLR objects. • The CLR guarantees that a delegate points to a valid method. • You get the benefits of function pointers without the dangers. • Each delegate is based on a single method signature. • Commonly used for callbacks. • Delegates are basis of event handlers.

38. Deployment • The CLR does not require registry entries for assemblies or managed types. • Assemblies can be deployed using the Windows Installer, Internet Explorer, or XCOPY. • Apps can be run from a CD with no installation at all. • Side-by-side deployment means you can create new versions of an assembly without having to maintain backwards compatibility with previous versions. • Both versions of the same assembly can run together (in the same address space on the same machine) - supporting both old and new clients.

39. The Bigger Picture? • The CLS and CTS are actually a part of a bigger specification called the CLI (Common Language Infrastructure). • The CLI and C# have been submitted to the ECMA for standardization. • MSIL and the CLR are simply Microsoft implementations of the CLI for Windows. • Open-Source organizations are developing .NET ports for other operating systems. • MS is helping Corel with a .NET port to FreeBSD. • The Free Software Foundation and Ximian are working on a .NET port to Linux.

40. The Framework Class Library

41. What is the Framework Class Library • The FCL is a hierarchical class library that can be utilized across multiple languages (CLS) and platforms (Windows). • Enables consistent programmatic access to the .NET runtime environment. • Integrates the functionality from existing COM and other runtime libraries. • Windows API, Data Access, XML, etc. all accessible in a consistent, simplified, unified way.

42. What is the Framework Class Library • Contains thousands of reusable classes, interfaces, and components that can be used for: • Accessing the file system, text files, and databases. • Working with XML. • Developing components and Web Services. • Managing application configurations. • Working with Directory Services, Event Logs, Processes, Message Queues, and Timers. • Handling images and strings. • Creating and managing threads. • Accessing assembly metadata and managing the CLR. • Developing Windows Forms applications. • Developing Web Forms applications. • Managing application security.

43. Key Features and Benefits • Cross-Language Interoperability • Consistent and Unified Programming Model • Object-Oriented and Extensible Class Library

44. Namespaces • A Namespace is a user-defined scope in which managed types are defined. • The FCL is organized into 98 namespaces. • FCL namespaces are organized in a hierarchy. The System namespace is at the topmost level, and almost all other namespaces are subordinate.

45. COM InterOp • “Classic COM” components can be used in a .NET application, and vice-versa. • ASP.NET and VB.NET still support CreateObject(). • C# can call COM servers via the InteropServices and Reflection routines. • Interop layer automatically converts errors (HRESULTS) into ComException exceptions. • The Type Library Importer utility takes a standard COM type library and creates an assembly containing the equivalent .NET metadata. The resulting DLL is essentially a mananged-code face on the COM component. • Best practice is to recompile the components.

46. ASP.NET

47. Key Features and Benefits • Better Performance. • Script code replaced by the .NET languages. • Code is JIT compiled (or pre-compiled). • Early binding, strong typing, better error handling. • Better Programming Models. • ASP.NET part of the FCL. • All ASP code consists of subclassed framework classes. • Less Coding. • Control state is built-in. • More data-bound controls. • Easier to use Components. • DLLs can be replaced in the procedure cache without stopping the site. • No more COM/MTS registration issues. • Extensive Caching Features.

48. Configuration • All configuration is done via an XML file - Web.config. • Web.config files are stored in the same virtual directory tree as the rest of the application files. • Can be changed on the fly, or redeployed using XCOPY, without stopping the site. • A Web.config can exist for each application. Config files inherit settings from parent config files. • Additional sections and elements can be added for application-specific settings.

49. Global.asax • Replaces (and is completely compatible with) the Global.asa file. • Provides for application-wide event handlers and other global logic for the web application. Applies to both the Web Forms and Web Services programming models. • Can contain the following: • Application Directives. • Code Declaration Blocks. • Server-side Object Tags. • Server-side Include Directives.

50. Session State Management • All session state is (by default) stored externally from the “worker” processes in dedicated “.NET State Server” processes running as separate NT processes. • No end-user code, and no live object references reside in these processes. • This process isolation improves ASP.NET’s reliability. • State Server can be a separate machine available to all web servers in a web farm. • Session Id strings are 120-bit keys. Passed between page requests via either an HTTP cookie or a “munged URL”. • “State Blobs” can be stored in SQL Server database.