Assembly

Where it all gets physical

Objectives

Introduce concepts of assemblies

Discuss elements of assemblies

Show how to build assemblies

Runtime aspects

Contents

Section 1: Overview

Section 2: Concepts and Elements

Section 3: Assemblies at Buildtime

Section 4: Assemblies at Runtime

Section 1: Overview

Versioning and DLL conflicts must be resolved Windows 2000 partially fixed DLL conflicts New shared version still replaces the old

Physical units instead of logical

Easy installation/deinstallation procedures required xcopy installation Just delete the files!

What‘s an Assembly

Runtime executable code = IL Single point of entry

Fundamental unit Version control Reuse Scoping Identity Security permissions

Runtime metadata

Static and Dynamic Assemblies

Static Generated by compilers Loaded from disk or downloaded from the net

Dynamic Built "on-the-fly" From scripts or via Reflection.Emit Can be transient

Assembly vs. Module

Module is compiled unit

Modules contain types and global methods

Assemblies contain modules

An assembly consists of modules and resources

Assembly manifest references files

Dependencies

Viewed as collection of exported resources Independent of implementation

Assembly may depend on other assemblies May import any public resource of other assembly

Types

Resource files

Etc.

Dependencies are recorded in the manifest

Resolved at runtime – no static linking

Type Referencing

Module2

Public Types

Assembly Types

ref: null, TypeA, module1

Module1

Public Types

Module Types

Public Types

Assembly Types

External Refs

Module3

Public Types

Module Types

Public Types

Assembly Types

External Refs

AssemblyA

AssemblyBref: null, TypeB, module2

ref: AssemblyB, TypeC, module3

Assembly vs. Namespace

Namespaces are used to group names

Assemblies can contain several namespaces

Namespaces can be partitioned across assemblies Types implemented twice are different!

Both must be included into project independently: Namespaces are imported in the source code

Assemblies are referenced by compiler switch

using System.Runtime.Remoting.Services;

csc /r:System.Runtime.Remoting.DLL ...

Section 2: Concepts and Elements

Elements of an assembly Manifest Versioning Security

Physical representation

What's in it's name

Manifest: Standard Elements Manifest is table with info records

Manifest contains info about: Assembly name Version information Strong name information Culture information Processor and OS Files that make up this assembly References to types and resources Exported and local types

Manifest: Custom Elements

AssemblyCompany

AssemblyConfiguration

AssemblyCopyright

AssemblyDefaultAlias

AssemblyDescription

AssemblyInformationalVersion

AssemblyProduct

AssemblyTitle

AssemblyTrademark

Multi-File Assemblies

Association based on metadata within assembly Not linked by the file system

Assembly.exe Module2.dll Graph.jpg

Assembly Manifest

Module Manifest

Module1 Module2 Graph

Versioning

Manifest carries version information

Compatibility version Major, minor, build, revision: 2.1.1254.0

Informational version String stored in AssemblyInformationalVersion

References to other assemblies carry version info

Side-by-side execution

Run different versions simultaneously Per machine Or even per process

Requires special coding considerations Issues with dependencies on machine resources Process-wide resources

Security Considerations

Integrity of files is guaranteed by hash verification

Assembly carries permission requests

Security policy is applied to requests at load time

AuthentiCode digital signing

Strong names

Strong Names

Simple name accompanied by: Public key Digital signature

Generated from assembly and private key

Prevent others from „taking over your namespace“

Protect version lineage

Assemblies with same strong name are identical

Versioning only works with strong named assemblies

Strong Name Utility

sn.exe provides options for: Signature generation

Generate public/private key pair

Key management Signature verification Setting Cryptographic Service Provider (CSP)

sn –k keyFile.snk

Assigning a Strong Name

Need to have a public-private key pair

Using attributes

Using al (assembly linker)

[assembly:AssemblyKeyFile("sgKey.snk")]

[assembly:AssemblyKeyName("AContainer")]

al myModule.dll /keyfile:sgKey.snk ...

Delaying Strong Name Assignment

Access to private key might be restricted

Delayed (or partial) signing reserves space in file Actual signing is deferred

Process works as follows: Developer works with public key file only

Verification must be switched off

Full signing must be applied later

[assembly:AssemblyKeyFile(„pubKey.snk")] [assembly:AssemblyDelaySign(true)]

sn –Vr myAssembly.dll

sn –R myAssembly.dll fullKey.snk

Using Strong Named Assemblies

Consumer of strong named assembly uses token Token is portion of public key

Runtime verifies strong name signature

Referencing usually transparent Compiler inserts token of referenced assembly Dynamic loading requires explicit notion

> sn –t myDll.DLL

Assembly.Load(“myDll,Version=1.0.0.1,Culture=neutral,PublicKeyToken=9b35aa32c18d4fb1”);

Section 3: More Tools and Deployment

Assembler ilasm

Disassembler ildasm

Global Assembly Cache

Installation

Assembler: ilasm

"Assembles" IL streams into loadable files Generates the metadata

Output can be disassembled by ildasm No optimizations made

Dis-Assembly: ildasm

"Disassembles" assemblies (or modules) into IL

Output can be reassembled by ilasm

GUI for examining an assembly Manifest Metadata IL code

Global Assembly Cache Advantages

Using the GAC has advantages: Performance improvements Integrity checking File security Versioning Automatic pickup of Quick Fixes Additional search location

Installation

Private vs. shared assemblies Private assemblies deployed in local directory Shared assemblies stored in Global Assembly Cache

Cache viewer as shell extension (shfusion.dll) Snap-In for Management Console (mscorcfg.msc)

gacutil –i myAssembly.DLL

Section 4: Assemblies at Runtime

Loading an assembly

Concept of Application Domain

JITting an assembly

PreJITting an assembly

Loading an Assembly

Assembly is Portable Executable (PE) file ... ... with CLR related information added

Runtime aware environment loads assembly directly

Unaware operating system loads assembly as PE Entry point: stub that loads and calls CLR CLR examines addtional header information

Application Domain

Concept for application isolation

Provide isolation at lower cost than processes

AppDomains are created by the runtime host

AppDomain is created for each application

Direct references between AppDomains disallowed Requires proxies or copied objects

Loader Optimization

Assembly is SingleDomain by default Each AppDomain loads and compiles assembly

Assembly can be marked for MultiDomain use Assembly is compiled once Mapped into all referencing AppDomains A copy is available for each process References to static data is indirected Assembly is unloaded when process ends

MultiDomainHost Copy of code is hosted in each AppDomain

Just-In-Time Compilation

MSIL is made for compilation Needs some per-method analysis

Code is compiled when needed Compilation on a per-method base Code that is not called is not compiled Loader creates stub for each method

First step: Verification of type safety

JITted code is not persisted

PreJITting with ngen

Complete compile at installation time PreJITted assembly is installed in GAC

Speeds up loading time significantly Both IL and native image are loaded No verification needed

Native image is not used... ...When module version ID of IL is different ...If the same applies to any dependencies ...Assembly binding policy has changed Fallback to normal JIT process

Summary

Assemblies as logical DLLs

Anatomy of an assembly

Units of versioning Strong names

Installation in Global Assembly Cache

Loading and Compiling

Questions?