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 AssemblyB ref: 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.exeModule2.dllGraph.jpg Assembly Manifest Module Manifest Module1Module2Graph

Versioning Manifest carries version information Compatibility version Major, minor, build, revision: 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= , 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?