1. Application Deployment and Versioning Source: Joe Hummel, kursus i .Net, jan. 2003

2. Objectives “Before .NET, the Component Object Model (COM) was the prevalent application design model. .NET replaces COM with an entirely new model that is programming-language independent, registry-free, tamper-resistant, and version-aware …” • Assembly navngivning • Versionsstyring • Deployment

3. Del 1 • Assembly naming…

4. object object object Remember component based developement • Application layers gives many components / classes • Example: • A typical stand-alone GUI app has 3 components • Packed as 1 EXE and 2 DLLs Front-end app.exe data.dll business.dll

5. Remember assemblies • 1 assembly = 1 or more compiled classes • .EXE represents one assembly with classes + Main program • .DLL represents one assembly with classes code.vb code.vb code.cs Development Tools assembly .EXE / .DLL

6. Assembly names • An assembly may have a 4-part "name": • Friendly, for humans readable name • culture • version number • public key token DataComponent, Culture=neutral, Version=1.0.0.0, PublicKeyToken=1234567890abcdef

7. Assigning name • Friendly, for humans readable name: • Required • set by Project properties >> Assembly Name • Culture • Version number • Public key token optional, set by .NET attributes

8. Assembly-level attributes • Visual Studio projects uses a special file for these • See "AssemblyInfo.cs" using System.Reflection; . . . [assembly: AssemblyDelaySign(false)] [assembly: AssemblyKeyFile(@"..\..\pubpriv.key")] [assembly: AssemblyVersion("1.0.0.0")] [assembly: AssemblyCulture("")] // neutral

9. Recall reference to assembly • When assembly A referes to assembly B… • …metadata are stored in both assembly manifests extern Component App.exe Public Key Token (8 bytes) Version PE/COFF Header CLR Metadata Code /r:Component.dll Signature Public Key Component.dll (128 bytes + 32 byte header) Version PE/COFF Header CLR Metadata Code

10. .NET is version-avare • By default CLR loads only the exact version • The program stops if the exact version can not be found • Example: • App.exe is compiled to v1.0.0.0 of Component.dll • then App.exe only runs if v1.0.0.0 can be loaded • NOTE: version-avare loading requires that the assembly has a "strong name" …

11. .NET is tamper-proof • CLR uses cryptography to avoid tampering • assemblies can be digitally-signed • based on public / private key encrypting • CLR cannot load the assembly, if it suspects tampering • is the client's public key not correct (the DLL replaced by a hacker?) • digitial signature doesn't match(the DLL replaced by a hacker?) • Assemblies with a digital signature has a "strong name"

12. Generate a public-private key pair • use "SN" command-line utility • -k option generates key pair • place the file in the root of the Visual Studio project folder

13. Protect the key file! • The key file is the key to ensure the security You don't want all your developers has access to it… • This is why Visual Studio don't supports key generation • have to use a command-line tool • and why .NET supports "delayed" signing • Developers works with unsigned assemblies in-house • Before deployment the deploy team signs the assemblies with the key using System.Reflection; . . . [assembly: AssemblyDelaySign(true)]

14. Part 2 • Version control…

15. version control problem • Problem: • application A uses component B • you want to make a new version of B • is it hereafter safe for A to use the new version of B?

16. Version control in .NET • Version control in .NET is very simple: • CLR loads only the assembly if the version number matches precisely • if you want the app shall use a new version then don't change the version number • if you don't want the app to use the new version then change the version number • There is a third posibilty, see later.....

17. Del 3 • Deployment…

18. Deployment • the registry database is gone in .NET • How are apps / assemblies deployed? • In a way we return to the (good?) old days with DOS • CLR uses a wellknown search algoritm • Customize searching by .config (".ini") files

19. What are the options? • Private assembly (APPBASE) • install EXE / DLLs in the same directory • easiest form of deployment ("xcopy") • Global assembly cache (GAC) • install DLLs into GAC • allows you to share DLLs, install different versions • allows you to pre-JIT • Download cache (CODEBASE) • you can tell CLR where to download from • allows you to install / upgrade from server • users can also download via Internet Explorer (URL to .exe)

20. Further options... • Use web services (like option 3) • In .Net 3.0+ / WPF run in the browser(msie, firefox....) or as a windows app. • Use Silverlight (as in Flash)

21. Recall the GAC… • Global Assembly Cache • How to put something in the GAC? • administrator rights are need'ed • assembly must have a “strong name” • use "gacutil" command-line tool:

22. Assembly search algorithm (approx) Assumes CLR is looking for anassembly based on 4-part name Apply Version Policy Use file found in Match in Y Global Cache? Global Cache N Is file found CODEBASE hint N via probing dir? N provided? Y Y Assembly.Load Does file match Does file match N N reference? Fails reference? Y Y Use file found Use file found at from probing dir CODEBASE

23. Config files • XML-based config files can be used for controlling CLR loading • Examples: • load another version of an assembly • download assembly from a given server

24. Example #1 • Version redirect • App.exe is compiled against v1.0.0.0.0 of Component.dll • we want that App.exe uses version 2.0.0.0 App.exe.config <configuration> <runtime> <assemblyBindingxmlns="urn:schemas-microsoft-com:asm.v1"> <dependentAssembly> <assemblyIdentity name="Component" publicKeyToken="1234567890abcdef"/> <bindingRedirect oldVersion="1.0.0.0" newVersion="2.0.0.0"/> </dependentAssembly> </assemblyBinding> </runtime> </configuration>

25. Example #2 • Download assembly to download cache • Specify assembly location by CODEBASE hint App.exe.config <configuration> <runtime> <assemblyBindingxmlns="urn:schemas-microsoft-com:asm.v1"> <dependentAssembly> <assemblyIdentity name="Component" publicKeyToken="1234567890abcdef"/> <codeBase version="2.0.0.0" href="http://company.com/downloads/Component.dll"/> </dependentAssembly> </assemblyBinding> </runtime> </configuration>

26. Summary • .NET supports full component based developement • .NET development deployment seems to be better: • programming language undependent • no registry • version-aware • tamper-resistant • My fear? • "DLL hell" to be replaced by ".config file hell"…

27. References • Books: • J. Richter, "Applied Microsoft .NET Framework Programming" • Web sites: • http://msdn.microsoft.com/net/ • Download-based deployment: • http://msdn.microsoft.com/msdnmag/issues/02/07/NetSmartClients/default.aspx • http://msdn.microsoft.com/code/default.asp?url=/code/sample.asp?url=/msdn-files/026/002/880/msdncompositedoc.xml • http://www.gotdotnet.com/team/windowsforms/appupdater.aspx