Prologue to the Microsoft Framework for Delphi Developers - PowerPoint PPT Presentation

introduction to the microsoft net framework for delphi developers l.
Skip this Video
Loading SlideShow in 5 Seconds..
Prologue to the Microsoft Framework for Delphi Developers PowerPoint Presentation
Prologue to the Microsoft Framework for Delphi Developers

play fullscreen
1 / 39
Download Presentation
Download Presentation

Prologue to the Microsoft Framework for Delphi Developers

Presentation Transcript

  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.


  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 •

  39. The Finish Line • Contact Information • Evaluation Forms • Questions & Answers Ray Konopka