Introduction to the Microsoft .NET Framework for Delphi Developers

1. Introduction to theMicrosoft .NET Framework for Delphi Developers

2. Agenda • Delphi and .NET • What is the .NET Framework? • .NET Framework Core Features • Writing .NET Managed Code • Programming in Delphi for .NET

3. Origins of .NET • The .NET Framework was influenced by many languages and frameworks • But there is no question that it looks a lot like Delphi and the VCL

4. Delphi or .NET? • Single-inheritance Object Hierarchy • Strongly Typed • Formal concept of properties and events • Consistent use of exceptions • Reusable and extensible component model • Formal notion of class interfaces • Special DLLs containing metadata (RTTI) and code • WinForms (VCL).

5. Migrating to .NET • Shorter learning curve for Delphi developers • Already familiar with object-oriented programming • Well versed in component-oriented programming • Comfortable consuming and creating events • Already know the benefits of exceptions and how to use them • Do not have to throw away existing Delphi development knowledge • Delphi 8 provides a clear migration path to .NET.

6. What is the .NET Framework? CIL BDP FCL CLS JIT ASP.NET CUBS ADO.NET GAC VCL.NET CLR VES GC RTL.NET TLA

7. What is the .NET Framework? • Virtual Machine Execution System • The Common Language Runtime (CLR) • Language-Neutral Class Library • The Framework Class Library (FCL) • Successor to Win32 Application Programming Model • Competitor to Java Platform

8. Common Language Runtime • Serves as the execution engine for managed applications • Activates objects • Performs security checks • Manages memory allocations and recovery • Executes code • etc.

9. Framework Class Library • Object-oriented API for writing managed applications • Defines more than 7,000 types • classes • interfaces • enumerations • delegates

10. .NET Framework Core Features • Simplified & Consistent Programming Model • Side-by-Side Execution and Versioning • Simplified Deployment • Multi-platform Support • Programming Language Integration • Garbage Collection • Code Verification • Consistent Error Handling • Interoperability

11. Simplified Programming Model • All operating system services accessed through common object-oriented programming model • File Access • Data Access • Threading • Graphics • etc. • The CLR removes many cumbersome concepts • Registry, GUIDs, IUnknown, HRESULTS, • etc.

12. Side-by-Side Execution/Versions • The CLR allows application components to be isolated • The CLR will always load the components that were used to be build and test the application. • If an application runs after installation, it should always run • Multiple versions of an application component may be installed on the same system • DLL versioning issues (DLL Hell) are eliminated

13. Simplified Deployment • Installing most .NET applications involves • Copying files to a directory • Adding a shortcut to Start menu, desktop, or Quick Launch bar • Registry access no longer needed • No more GUIDs, ProgIDs, ClassIDs, etc. • To uninstall, just delete the files

14. Multi-Platform Support • .NET source code compiled to Common Intermediate Language(CIL) instead of traditional CPU instructions • High-level CPU independent assembly language • ~100 different instructions • Direct support for object types, exceptions, etc. • DCCIL compiles Delphi source code into CIL

15. Multi-Platform Support • At runtime, the CLR translates the CIL into native CPU instructions • Resulting CPU instructions are optimized for the host processor • A .NET application can be deployed to any machine that has an ECMA-compliant version of the CLR and FCL • e.g. x86, IA64, Pocket PC, Linux (via Mono), etc.

16. Language Interoperability • The CLR allows different programming languages to share types • The CLR provides a Common Type System (CTS) • Describes how types are defined and how they behave • Specifies the rules for type visibility and members access • Single inheritance - System.Object • Common Language Specification (CLS) • Defines the minimum set of features that all .NET languages that target the CLR must support

17. CLR/CTS & CLS Relationship CLR/CTS C# Delphi CLS Others • Each language supports • A subset of the CLR/CTS • A superset of the CLS

18. Garbage Collection • The CLR automatically tracks all references to memory • When a block of memory no longer has any “live” references to it, it can be released and reused (collected) • Impact – No deterministic destruction of objects • IDisposable for releasing resources • GC in the CLR covered in detail in February 2004 issue of The Delphi Magazine by Julian Bucknall.

19. Garbage Collection and Delphi • Destructors in Delphi source code are translated into IDisposable pattern • Free is still available in Delphi 8 • Programming pattern for reference types same as before—use Free when finished. begin List := TStringList.Create; try . . . finally List.Free; // Calls Dispose if implemented end;

20. Code Verification • The CLR can verify that all your code is type-safe • The CLR ensures that allocated objects are always accessed appropriately • Correct number of parameters • Correct types of parameters • No inappropriate memory access • etc. • The CLR also ensures that execution flow will only transfer to well-known locations • Method entry points

21. Consistent Error Handling • Traditional Win32 programming incorporates many different error handling mechanisms • Status Codes • GetLastError • HRESULTS • Structured Exceptions • In the CLR, all failures are reported via Exceptions • Exceptions work across module and programming language boundaries • An exception raised in a Delphi class can be handled in a VB.NET exception handler

22. Interoperability • The .NET Framework supports interoperability with existing code and components • Managed code can call an unmanaged function in a DLL • P/Invoke – Platform Invoke • Managed code can use an existing COM component (server) • Managed assembly created from type library • Unmanaged code can use a managed type (server) • TlbExp.exe – Assembly to Type Library Converter • RegAsm.exe – Assembly Registration Utility

23. Writing .NET Managed Code • Managed Modules • Assemblies • Namespaces • Manifests • AppDomains • Safe Code vs. Unsafe Code

24. Managed Modules • An executable designed to be run by the CLR • Typically has EXE, DLL, or NETMODULE extension • Contains • Windows Portable Executable (PE) File Header • A CLR header • Metadata describing contents and external dependencies • CIL instructions generated from source code • However, the CLR cannot execute a managed module directly • Must be part of an assembly

25. Assemblies • Logical grouping of one or more modules or files • Smallest unit of reuse, security, and versioning • Assemblies can be created • Directly by compiler (e.g. DCCIL.exe, CSC.exe, VBC.exe) • By combining existing modules using AL.exe (assembly linker) • Satellite Assemblies • Contain resource data (strings, icons, etc.) • Loaded at runtime based on user locale • Note: The CLR loader considers a .NET executable is an assembly

26. Assemblies and Delphi • Very similar to Packages in Delphi • In fact, you create assemblies using the Delphi package syntax • requires clause lists dependent assemblies (including .NET Framework assemblies) • contains clause lists units to be included • Example • RayKonopka.BorCon2004.Samples.dpk

27. Namespaces • A namespace is a logical container for types • Designed to eliminate name collisions • Namespaces do not have any physical manifestation • Unlike Java, they do not map onto a directory structure • An assembly can contribute to multiple namespaces • Multiple assemblies can contributed to a namespace • Examples • System.Drawing • System.Windows.Forms

28. Namespaces in Delphi • A Delphi project (program, library, or package) implicitly introduces its own namespace called the project default namespace. • A unit may explicitly declare itself to be part of a namespace in the unit header • unit RayKonopka.Common.StringUtils; • Namespace = RayKonopka.Common.StringUtils • A generic unit automatically becomes part of the project default namespace • unit RkStringUtils; • Namespace = RayKonopka.BorCon2004.RkStringUtils

29. Multi-unit Namespaces • One of the criticisms of Delphi 8’s support of namespaces is that multiple units cannot belong to the same namespace • This is no longer an issue with Diamondback—the next version of Delphi.

30. Manifests • An XML description of the contents and external dependencies of a managed module • A manifest specifies the exact version of a module that should be loaded to satisfy an external reference • Internal - Manifest can be embedded as resource • External - Manifest file can be placed in same directory as executable. Must have same base filename as module. • RayKonopka.Controls.dll.manifest

31. AppDomains • An Application Domain is a context in which one or more assemblies may be loaded • An AppDomain is the smallest granularity of code disposal • You cannot unload an assembly • You can unload an AppDomain, which will dispose of all the assemblies loaded into it • By default, every managed executable will run in its own, separate process that has just one AppDomain • However, the CLR supports loading multiple AppDomains into a single process

32. AppDomain Boundaries • Objects in one domain cannot be accessed by code in another domain • Data passed between domains must be marshaled across the domain boundary

33. Safe vs. Unsafe Code • Managed code DOES NOT mean safe code • Safe code is code that is verifiably safe • PEVerify.exe • Safe code • does not improperly access memory • does not call methods with inappropriate parameters • cannot adversely affect another application’s code • etc. • Code that cannot be verified is considered unsafe • Call external APIs (external to .NET) • Using pointers and other unsafe types

34. Unsafe Types in Delphi • Data types that work with pointers in some way are considered unsafe • PChar • Untyped Pointers • file of <type> • Variant Records • Untyped out and ref parameters • Real48 (i.e. 6 byte floating point numbers)

35. Unsafe Code in Delphi • Unsafe code accesses or works directly with memory and cannot be verified to be safe • BlockRead • BlockWrite • Addr • Ptr • Absolute

36. Unsafe Typecasts in Delphi • An unsafe typecast occurs when you cast an object to a type that is not an ancestor or descendant of the object instance var NumList: TStringList; procedure AddNumber(Caption: string; Value: Integer); begin NumList.AddObject( Caption, TObject( Value ) ); end;

37. Additional Sessions • 1178 - Introduction to .NET FCL – Corbin Dunn • Monday, 2:00 pm to 3:15 pm • Wednesday, 11:00 am to 12:15 pm • 3228 – Custom .NET Controls – Ray Konopka • Monday, 5:00 pm to 6:15 pm

38. References • Delphi for .NET Developers Guide • Xavier Pacheco • Microsoft Development Network (MSDN) • Applied .NET Framework Development • Jeffrey Richter • Programming Microsoft .NET • Jeff Prosise • .NET Reflector by Lutz Roeder • http://www.aisto.com/roeder/dotnet

39. The Finish Line • Contact Information • Evaluation Forms • Questions & Answers Ray Konopka rkonopka@raize.com http://www.raize.com