Loading Assemblies in Extensible Applications By Avinash R

Loading Assemblies in Extensible Applications By Avinash R. Prasad

What are extensible applications? l l Provide the ability to change the basic features of a program or add new features without recompiling Provide the ability to load in and execute new code, including code written after program is shipped Built using reflection, interfaces & dynamically loaded assemblies Examples: IE 6, Visual Studio. Net 2003, SQL Server

Concepts and Terminology Assembly names: Strong & Weak (used for locating assemblies) l Binding references: Early Vs Late l Specifying references: Fully Vs Partially l Version policy l

Strong & Weak Names l Assembly’s identity consists of 4 parts: l l Friendly name : File name without the extension Version: String with 4 dot-limited numbers, major version, minor version, build number & revision number Public key: Unique value to map a company or developer, occupies 128 bytes Culture: Two letter code indicating localization for a particular language, can carry country code

Strong & Weak Assembly Names (Contd. ) l l l Strong name when assigned cryptographic key pair, else weak name (done with compiler or sn. exe) to ensure security Strong names used when intended to share among several applications Strong name files have digital signatures embedded in the file containing the manifest Strong name contains public key used to generate signature For more info. lookup Applied Microsoft Framework Programming by Jeffrey Richter

Early Vs Late Binding Early bound references recorded in metadata when assembly is compiled l Late bound references specified on the fly using APIs on System classes l Extensible applications to use both l. assembly extern statement represents early bound reference to an assembly l We shall focus on late binding l

Fully and Partially specified references When all four fields are specified, assembly reference is said to be Fully specified l If any field missing, it is Partially specified, results in looser binding semantics l ASP. NET uses partial binding and weakly named assemblies l

Version Policy l l CLR uses strict version checking to minimize conflicts between different versions, loads exact version by default However can be overridden by series of statements called version policy. Set in XML files Has 3 levels: l l l Author of application Publisher of shared assembly Machine administrator

Extensible Application’s use of App Domains Multiple app domains used to isolate addins l App domain manager (Ch. 5) created for each app domain to call assembly loading APIs l Add-in assemblies not loaded in default app domain l Communication between app domains limited to app domain managers l

Extensible applications architecture

Key design issues Limit volume of communication in terms of number of calls and data passed l Limit number of assemblies involved in calls across app domains (as an assembly must be loaded in both app domains) l Both app domains must be unloaded to completely remove assembly from process l

System. Reflection. Assembly l l Recall that calling a method on a type in another app domain is a remote call Types used are marshaled by value and marshaled by reference (derive from System. Marshal. By. Ref. Object) Type used to represent assemblies in. Net is marshaled by value, not by reference!! So, instance of assembly must be loaded into the app domain where instance resides

Effects of marshal by value l Add-in assembly must be loaded into our default app domain, so can’t unload without terminating entire process l Can also lead to security breaches if policy in that domain is not configured correctly l Complication in deployment when specifying Application. Base l CLR tries to load assemblies into app domain never intended

Steps followed when loading a new add-in Extensible apps made aware of new addin (thro’ user interface or config file) l App domain is chosen in which to load (eg. all apps from same site in same app domain) l App domain manager in target domain is called to load add-in l App domain manager in target domain loads the add-in l

. Net provided methods to load assemblies l l l l App. Domain. Load - load into other app domains App. Domain. Execute. Assembly. By. Name – executes code when called App. Domain. Create. Instance. And. Unwrap Assembly. Load – static method, so can load only in current app-domain Assembly. Load. With. Partial. Name – deprecated in 2. 0 and will be removed in future versions Activator. Create. Instance

Ways to specify assembly identities Specifying assembly identities with strings l Specifying assembly identities with System. Reflection. Assembly. Name l

Specifying Identities as Strings “[friendly. Name], Version=[number], Public. Key. Token=[token], Culture=[culture]” l friendly. Name must come first while others can be in any order l Incorrect assembly names result in File. Load. Exception l If any of them not specified, then we have Partially Specified Assembly Reference l

Specifying Identities using System. Reflection. Assembly. Name Has properties and methods to identify assembly to load l Property Name l Property Version l Property Culture. Info l Method Set. Public. Key (byte[]) l Method Set. Public. Key. Token (byte[]) l

How CLR locates assemblies Application. Base – root directory, intended to be private for that domain l Global Assembly Cache (GAC) – CLR looks here first to resolve reference to strongly names assembly l Version Policy – XML configuration file l Codebases – Same config file with <codebase> XML element l

Locating assemblies with weak names l Looks for codebase in app config file l Add-in comes with own application configuration file Not likely to be used often as user will have to modify Configuration. File property in own application to use it l Probe for assembly in Application. Base or its subdirectories – loaded by name only l

Locating assemblies with strong names l Steps to resolve reference l Determine version of assembly to load from the 3 version policy files l Look in GAC for assembly l Look in configuration files for any codebase locations l Probe in Application. Base and its subdirectories

Advantages of loading assembly from GAC l Better overall system performance l Loading from same location on disk uses less memory l OS loads DLL’s read-only pages once and shares them among all instances l Efficient verification of strong name l Verification process long and tedious l Only verified when installed into the GAC

Fuslogvw. exe Logs each step CLR completes when resolving reference to a library l Useful for diagnosing errors and understanding loading process l Has two modes of running l l Log every attempt to load an assembly l Log only those attempts that fail

Fuslogvw. exe (Cont. )

Assembly loading exceptions System. IO. File. Not. Found. Exception – not found by CLR l System. IO. File. Load. Exception – when CLR encounters an error when parsing assembly name string passed to one of the APIs l System. Bad. Image. Format. Exception – when file is not managed code l

How CLR resolves partially specified assembly references Looks in Application. Base – if strongly names found in Application. Base, then looks in GAC, searches version policy etc. l Public key token checked against assemblies in Application. Base, if not then File. Load. Exception is thrown l If version is specified with friendly name and assembly has weak identity, assembly is loaded nonetheless l

Critical issues related to Assembly. Load. From CLR must ensure that assemblies loaded dynamically by filename do not conflict with statically referenced assemblies l So, CLR isolates assemblies loaded statically from those loaded dynamically using binding contexts l Binding contexts are Load Context and Load. From Context l

Assembly. Load. From scenario

Other scenarios CLR must make sure that types of the same name from different binding contexts are not mistaken for each other as problems occur during typecasting l If two assemblies from different locations but same weak name are attempted to be loaded, only one is loaded l

Versioning considerations l l Add-in could be built with different version of. Net, so version conflict All versions of. Net are compatible with previously released versions i. e. backward compatible Do not load add-ins from newer versions into applications written in previous versions Loading add-in built in previous version into application in newer version OK

Versioning considerations (Contd. ) l l Application designer can pick which version of CLR to load into his process Once CLR selected, consistent set of assemblies will be loaded into process (Unification) If unification causes problems, override in application config file the choice of CLR to load Image. Runtime. Version used to determine version of CLR and. Net used

Microsoft. Net Framework Unification – Possible scenario

Unification (Contd. ) l Two possible solutions l l Load multiple versions of. Net framework libraries into same process Redirect various references to single version of. Net Framework assemblies Insufficient testing carried out my Microsoft to support these scenarios So, CLR redirects all references to assemblies matching the CLR loaded into the process

Unification (Contd. )

Summary All add-in assemblies to be loaded in a late -bound fashion l Use. Net’s API methods for loading l Implement version policy where appropriate l Use provided tools such as fuslogvw. exe for debugging l

What’s coming in Version 2. 0 l Reflection. Only APIs - load exact file, no policy, no second-bind l Assembly. Reflection. Only. Load. From l App. Domain. Reflection. Only. Get. Assemblies l App. Domain. Apply. Policy l Type. Reflection. Only. Get. Type

References Customizing The Microsoft. Net Common Language Runtime – Steven Pratschner l Extensible Applications: New features without recompiling – Joe Wirtley http: //msdn. microsoft. com/library/default. asp ? url=/library/enus/dnhcvs 04/html/vs 04 f 1. asp l

Thanks for listening!! Goodbye!!