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 [Link]
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
Public Types External
Refs
Assembly Types
Public Types External
Refs
Assembly Types
Module3
Module2 Public Types
Module1
Public Module Types
PublicTypes
Types
Assembly
ModuleTypes
Types
ref: null, TypeA, module1
ref: null, TypeB, module2
AssemblyB
ref: AssemblyB, TypeC, module3
AssemblyA
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
using [Link];
Assemblies are referenced by compiler switch
csc /r:[Link] ...
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
Module1 Module2 Graph
Assembly Module
Manifest Manifest
[Link] [Link] [Link]
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
[Link] provides options for:
Signature generation
Generate public/private key pair
sn –k [Link]
Key management
Signature verification
Setting Cryptographic Service Provider (CSP)
Assigning a Strong Name
Need to have a public-private key pair
Using attributes
Using al (assembly linker)
[assembly:AssemblyKeyFile("[Link]")]
[assembly:AssemblyKeyName("AContainer")]
al [Link] /keyfile:[Link] ...
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
[assembly:AssemblyKeyFile(„[Link]")]
[assembly:AssemblyDelaySign(true)]
Verification must be switched off
sn –Vr [Link]
Full signing must be applied later
sn –R [Link] [Link]
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 [Link]
[Link](“myDll,
Version=[Link],
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
gacutil –i [Link]
Cache viewer as shell extension ([Link])
Snap-In for Management Console ([Link])
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
