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?