Transcript Introduction to the Microsoft .NET Framework for Delphi

Introduction to the
Microsoft .NET Framework for
Delphi Developers
Ray Konopka
Agenda
 Delphi and .NET
 What is the .NET Framework?
 .NET Framework Core Features
 Writing .NET Managed Code
 Programming in Delphi for .NET
2
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
3
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).
4
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.
5
What is the .NET Framework?
CIL
CLS
ASP.NET
JIT
CUBS
GAC
CLR
BDP
VES
RTL.NET
GC
FCL
ADO.NET
VCL.NET
TLA
6
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
7
Common Language Runtime
 Serves as the execution engine for managed
applications

Activates objects

Performs security checks

Manages memory allocations and recovery

Executes code

etc.
8
Framework Class Library
 Object-oriented API for writing managed applications
 Defines more than 7,000 types

classes

interfaces

enumerations

delegates
9
.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
10
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.
11
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
12
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
13
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
14
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.
15
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
16
CLR/CTS & CLS Relationship
 Each language supports

A subset of the CLR/CTS

A superset of the CLS
CLR/CTS
C#
Delphi
CLS
Others
17
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.
18
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;
19
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
20
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
21
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
22
Writing .NET Managed Code
 Managed Modules
 Assemblies
 Namespaces
 Manifests
 AppDomains
 Safe Code vs. Unsafe Code
23
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
24
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
25
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
26
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
27
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
28
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.
29
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
30
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
31
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
32
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
33
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)
34
Unsafe Code in Delphi
 Unsafe code accesses or works directly with memory
and cannot be verified to be safe

BlockRead

BlockWrite

Addr

Ptr

Absolute
35
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;
36
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
37
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
38
The Finish Line
 Contact Information
Ray Konopka
[email protected]
http://www.raize.com
 Evaluation Forms
 Questions & Answers
39