Loading Assemblies in Extensible Applications

1. Loading Assemblies in Extensible Applications By Avinash R. Prasad

2. What are extensible applications? • 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

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

4. Strong & Weak Names • Assembly’s identity consists of 4 parts: • 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

5. Strong & Weak Assembly Names (Contd.) • 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

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

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

8. Version Policy • 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: • Author of application • Publisher of shared assembly • Machine administrator

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

10. Extensible applications architecture

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

12. System.Reflection.Assembly • 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.MarshalByRefObject) • 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

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

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

15. .Net provided methods to load assemblies • AppDomain.Load - load into other app domains • AppDomain.ExecuteAssemblyByName – executes code when called • AppDomain.CreateInstance • AppDomain.CreateInstanceAndUnwrap • Assembly.Load – static method, so can load only in current app-domain • Assembly.LoadWithPartialName – deprecated in 2.0 and will be removed in future versions • Activator.CreateInstance

16. Ways to specify assembly identities • Specifying assembly identities with strings • Specifying assembly identities with System.Reflection.AssemblyName

17. Specifying Identities as Strings • “[friendlyName], Version=[number], PublicKeyToken=[token], Culture=[culture]” • friendlyName must come first while others can be in any order • Incorrect assembly names result in FileLoadException • If any of them not specified, then we have Partially Specified Assembly Reference

18. Specifying Identities using System.Reflection.AssemblyName • Has properties and methods to identify assembly to load • Property Name • Property Version • Property CultureInfo • Method SetPublicKey (byte[]) • Method SetPublicKeyToken (byte[])

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

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

21. Locating assemblies with strong names • Steps to resolve reference • Determine version of assembly to load from the 3 version policy files • Look in GAC for assembly • Look in configuration files for any codebase locations • Probe in ApplicationBase and its sub-directories

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

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

24. Fuslogvw.exe (Cont.)

25. Assembly loading exceptions • System.IO.FileNotFoundException – not found by CLR • System.IO.FileLoadException – when CLR encounters an error when parsing assembly name string passed to one of the APIs • System.BadImageFormatException – when file is not managed code

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

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

28. Assembly.LoadFrom scenario

29. 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 • If two assemblies from different locations but same weak name are attempted to be loaded, only one is loaded

30. Versioning considerations • 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

31. Versioning considerations (Contd.) • 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 • ImageRuntimeVersion used to determine version of CLR and .Net used

32. Microsoft .Net Framework Unification – Possible scenario

33. Unification (Contd.) • Two possible solutions • 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

34. Unification (Contd.)

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

36. What’s coming in Version 2.0 • ReflectionOnly APIs - load exact file, no policy, no second-bind • Assembly.ReflectionOnly • Assembly.ReflectionOnlyLoad • Assembly.ReflectionOnlyLoadFrom • AppDomain.ReflectionOnlyGetAssemblies • AppDomain.ApplyPolicy • Type.ReflectionOnlyGetType

37. References • Customizing The Microsoft .Net Common Language Runtime – Steven Pratschner • Extensible Applications: New features without recompiling – Joe Wirtley http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnhcvs04/html/vs04f1.asp

38. Thanks for listening!! Goodbye!!