1 / 53

Deployment und Versioning von .NET Applikationen

Deployment und Versioning von .NET Applikationen. Uwe Baumann Technologieberater Developer Group Microsoft GmbH uwebaum@microsoft.com. Was Sie erwartet. Eine kurzer Überblick in den Problemkreis Die „DLL-Hölle“ und ihre Ursachen

moswen
Download Presentation

Deployment und Versioning von .NET Applikationen

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Deployment und Versioning von .NET Applikationen Uwe Baumann TechnologieberaterDeveloper GroupMicrosoft GmbH uwebaum@microsoft.com

  2. Was Sie erwartet • Eine kurzer Überblick in den Problemkreis • Die „DLL-Hölle“ und ihre Ursachen • Eine Einführung in die .NET-Technologien für Deployment und Versioning • Konfiguration von Applikationen mit Hilfe von Policy Files • Komponenten mit integriertem Setup-Code • Microsoft Installer (MSI) Support

  3. Anforderungen [1/3] • Unkompliziertes Deployment • "XCopy"-Installation • Einfaches physikalisches Verschieben von Applikationen • Verhinderung von "Nebenwirkungen" • Neue Applikationen sollen bereits installierte Applikationen nicht negativ beeinflussen

  4. Anforderungen [2/3] • Management von Software-Service • Wie können Bugfixes ausgeliefert werden? • Was tun, wenn der Bugfix neue Bugs enthält? • Was tun, wenn ein Bugfix für eine gemeinsame Komponente nur von einer Applikation genutzt werden soll?

  5. Anforderungen [3/3] • Einfache Installation von benötigten Ressourcen • Erstellen von Datenbanken • Setup von Message Queues

  6. Ein Beispielprojekt: "MyOffice .NET"

  7. "MyOffice"-Komponenten • MyText und MyCalc • "Textverarbeitung" und "Tabellenkalkulation" • .NET WinForms-Applikationen (EXE) • MySpeller • "Rechtschreibprüfung" • .NET Klassenbibliothek (DLL) • Gemeinsam genutzte Komponente –wird von MyText und MyCalc referenziert

  8. Applikations-Komponenten(Lokaler Speicherort) Gemeinsame Systemkomponenten(Zentraler Speicherort) "MyOffice" - Abhängigkeiten MyCalc.EXE System.Windows.Forms.DLL .NET Formularbibliothek NEUEVERSION! MyText.EXE MSCorLib.DLL .NET Basis-Datentypen NEUEVERSION! MySpeller.DLL System.Data.DLL .NET Datenzugriffs-Bibliothek

  9. Die „DLL-Hölle“… • Der „Highlander-Effekt“ bei DLLs:„Es kann nur eine(n) geben“  • Alle Clients müssen dieselbe DLL verwenden • Diese wird eventuell von einer anderen Applikation mit einer inkompatiblen Version überschrieben • Clients können keine „private Kopie“ der DLL verwenden oder eine bestimmte Version anfordern

  10. …und die .NET Runtime (CLR) • Die CLR kann verschiedene Versionen einer gemeinsam genutzten Komponente gleichzeitig ausführen • Jede Client-Applikation kann individuell die gewünschte Version anfordern • Extensive Konfigurationsmöglichkeiten • Komponenten enthalten alle wichtigen Informationen über sich selbst • Keine Eintragungen in der Registry mehr nötig

  11. Metadaten Imports System.IO Imports System.Data Imports Microsoft.Win32 Public Class MySpeller 'Simple "Rechtschreibprüfung", kann nur auf das Wort "HALLO" prüfen Public Shared Function CheckSpelling _ (ByVal DocumentString As String) As Boolean If DocumentString.ToUpper.Trim <> "HALLO" Then Return False Else Return True End If End Function Reference-Tabellen Was wird importiert? Definition-Tabellen Was wird exportiert? MSIL Code (kompiliert) .method public static bool CheckSpelling(string DocumentString) cil managed { // Code size 40 (0x28) .maxstack 3 .locals init ([0] bool CheckSpelling) IL_000c: ldstr "HALLO" IL_0011: ldc.i4.0 IL_0012: call IL_0017: ldc.i4.0 IL_0025: nop IL_0026: ldloc.0 IL_0027: ret } // end of method MySpeller::CheckSpelling Inside "MySpeller" • Jedes Modul enthält… • Metainformationen darüber, welche externen Typen, Methoden etc. von diesem Modul verwendet werden • Metainformationen darüber, welche Typen, Methoden etc. von diesem Modul exportiert werden • Optional: Ausführbaren Code (MSIL) MySpeller.DLL

  12. Assemblies • "Logische" EXE oder DLL unter .NET • Eine Assembly kann aus einem oder mehreren Files bestehen, ist aber nach außen eine logische Einheit • Versionierung, Deployment und Security beziehen sich jeweils auf die Assembly als Ganzes • Enthält ein Manifest, welches Auskunft über die Assembly gibt

  13. Metadaten Manifest Files Exporte Importe Single File Assembly • Jede Assembly enthält genau ein Manifest • Auch bei Single File Assemblies • Jedes File der Assembly enthält Metadaten über seine eigenen Typen und Methoden Exporte MSIL Code (kompiliert) MySpeller.DLL Assembly MySpellerVersion X

  14. Demo • "MySpeller" im MSIIL Disassembler ILDasm.exe

  15. Metadaten Metadaten Metadaten Exporte Exporte Importe Importe Importe Multi File Assembly Assembly MySpellerVersion X Manifest Files Exporte Exporte MSIL Code (kompiliert) MSIL Code (kompiliert) MSIL Code (kompiliert) MySpeller.DLL MySpellerTools.DLL … MyGrammar.DLL

  16. Demo • Erstellung einer Multi File Assembly

  17. Private und Public Assemblies • Private Assemblies • Befinden sich im Applikationsverzeichnis oder einem Unterverzeichnis davon • Werden nur von einer Applikation genutzt • Public Assemblies • Werden von einer oder mehreren Applikationen genutzt • Befinden sich an einem zentralen Ort, dem Global Assembly Cache (GAC)

  18. Der Global Assembly Cache • Speicherort für Public Assemblies • Kann mehrere Versionen derselben Assembly aufnehmen • Die CLR ist in der Lage, unterschiedlichen Applikationen verschiedene Versionen einer Assembly zu liefern und diese gleichzeitig im Speicher zu halten

  19. Identifizierung von Assemblies • Assemblies im GAC müssen eindeutig identifizierbar sein • Was passiert, wenn es zwei verschiedene MySpeller-Bibliotheken gibt? • COM-Lösung: Eindeutige GUID?

  20. Strong Names [1/3] • Strong Names liefern Identität • Teile der Metainformation werden mit einem Private Key digital signiert • Assemblies, welche die Public Assembly referenzieren, enthalten den entsprechenden Public Key • Strong Names sind sicher • Nur der Autor hat den Private Key und kann damit signieren • Manipulationen werden verhindert

  21. Hash-Wert Strong Names [2/3] Public Key Metadaten Manifest Private Key + .snk File MSIL Code (kompiliert) RSA Signatur MySpeller.DLL Assembly MySpeller

  22. Strong Names [3/3] Public Key Metadaten Manifest  A=B ? Private Key Hash-Wert A Hash-Wert B .snk File MSIL Code (kompiliert) + RSA Signatur RSA Signatur MySpeller.DLL Assembly MySpeller

  23. Demo • Der Global Assembly Cache (GAC)

  24. .NET Deployment: Grundregel • Verwenden Sie möglichst wenige Shared Assemblies! • Alle Private Assemblies, auf die Ihre Applikation verweist, können im Applikationsverzeichnis bzw. Unterverzeichnissen davon "leben" • Die gesamte Applikation kann so per "XCopy" an eine andere Stelle kopiert werden • Eine solche Applikation läuft beispielsweise auch direkt von CD!

  25. Shared Assemblies • Shared Assemblies sind trotzdem unvermeidbar • Systembibliotheken, Datenzugriffsbibliotheken uvm. • Änderungen an Shared Assemblies beeinflussen potentiell viele Applikationen(wie "einst" unter COM! ;-) • Bei negativen Auswirkungen auf einzelne Applikationen kann selektiv durch Konfigurationsfiles eingegriffen werden!

  26. Konfigurationsfiles [1/2] • "Human-readable" XML-Files • Bestimmen die Regeln für die Suche nach der richtigen Assembly("Assembly Binding") • Wo suchen? • Welche Version verwenden?

  27. Konfigurationsfiles [2/2] • Application Configuration Files • Bestimmen für jede Applikation einzeln, wie und wo nach Assemblies gesucht wird • Publisher Configuration Files • Leiten Aufrufe an einzelne Shared Assemblies auf neuere Versionen um (bei Bugfixes) • Machine Configuration Files • Gelten global für den gesamten Computer • Überschreiben Application Configuration

  28. Konfigurationsfiles editieren • „Per Hand“ mit Notepad • Mit PlugIns der Management-Konsole • Windows XP: Systemsteuerung  Verwaltung  .NET Framework Konfiguration

  29. Deployment Szenario 1 • Einfaches XCopy Deployment • Alle Files von MyOffice sollen in ein Applikationsverzeichnis

  30. Deployment Szenario 1 C:\PROGRAMME\MYOFFICE C:\WINNT\ASSEMBLY MyCalc.EXE MyText.EXE XCOPY MySpeller.DLL C:\PROGRAMME\MYOFFICE\TOOLS Global Assembly Cache Applikationsverzeichnis

  31. Demo • Deployment von „MyOffice“ per XCopy

  32. Deployment Szenario 2 • Verschieben von Komponenten in Unterverzeichnisse • MySpeller soll in das Unterverzeichnis \Tools unterhalb des Applikations-verzeichnis verschoben werden • Dieser Pfad muß im Application Configuration File eingetragen werden

  33. Deployment Szenario 2 C:\PROGRAMME\MYOFFICE C:\WINNT\ASSEMBLY MyText.EXE MyCalc.EXE Wo istMySpeller? MyText.EXE.config MySpeller.DLL <?xml version="1.0" encoding="utf-8" ?> <configuration> <runtime> <assemblyBinding xmlns="urn:schemas- microsoft-com:asm.v1"> <probing privatePath="tools;"/> </assemblyBinding> </runtime> </configuration> C:\PROGRAMME\MYOFFICE\TOOLS Global Assembly Cache Applikationsverzeichnis

  34. Demo • Verschieben der Komponente „MySpeller“

  35. Deployment Szenario 3 • "MySpeller" soll eine Shared Assembly werden • MySpeller muß einen StrongName bekommen • MySpeller.DLL muß in den GAC kopiert werden (Tool: GACUtil.EXE oder VS) • Die Runtime lädt jetzt MySpeller aus dem GAC, und nicht mehr aus dem Applikationsverzeichnis

  36. Deployment Szenario 3 C:\PROGRAMME\MYOFFICE C:\WINNT\ASSEMBLY MySpeller.DLL MyText.EXE MyCalc.EXE MyText.EXE.config Wo istMySpeller? C:\PROGRAMME\MYOFFICE\TOOLS MySpeller.DLL Global Assembly Cache Applikationsverzeichnis

  37. Demo • Signieren von „MySpeller“ und Installation im Global Assembly Cache

  38. Deployment Szenario 4 [1/2] • Ein neue Version von MySpeller ist verfügbar • Alle Applikationen, die MySpeller verwenden, sollen mit der neuen Version arbeiten • Ein Publisher Policy File kann die Aufrufe der alten Version an die neue Version "umleiten"

  39. Deployment Szenario 4 C:\PROGRAMME\MYOFFICE C:\WINNT\ASSEMBLY MySpeller.DLL Version 1.0 MyText.EXE MyCalc.EXE policy.1.0.MySpeller.DLL MyText.EXE.config MySpeller.DLL Version 1.5 C:\PROGRAMME\MYOFFICE\TOOLS <configuration> <runtime> <assemblyBinding xmlns="…" <dependentAssembly> <assemblyIdentity name="MySpeller" <bindingRedirect oldVersion="1.0.0.0" newVersion="1.5.0.0"/> </dependentAssembly> </assemblyBinding> </runtime> </configuration> MySpeller.DLL Global Assembly Cache Applikationsverzeichnis

  40. Demo • Deployment der neuen Version von „MySpeller“ und Konfiguration der Client-Applikationen

  41. Deployment Szenario 4 [2/2] • Moment mal… einige Applikationen haben Probleme mit dieser neuen Version! • Einzelne Applikationen können in ihrem Application Configuration File bestimmen, daß die vorherige Version verwendet wird ("Safe Mode")

  42. Deployment Szenario 4 C:\PROGRAMME\MYOFFICE C:\WINNT\ASSEMBLY MySpeller.DLL Version 1.0 MyText.EXE MyCalc.EXE policy.1.0.MySpeller.DLL MyText.EXE.config MySpeller.DLL Version 1.5 C:\PROGRAMME\MYOFFICE\TOOLS <?xml version="1.0" encoding="utf-8" ?> <configuration> <runtime> <assemblyBinding <dependentAssembly> <assemblyIdentityname="MySpeller"/> <publisherPolicy apply="no"/> </dependentAssembly> </assemblyBinding> </runtime> </configuration> MySpeller.DLL Global Assembly Cache Applikationsverzeichnis

  43. Demo • „MyCalc“ zur Verwendung der vorherigen Version von „MySpeller“ zwingen

  44. Komponenten mit integrierterSetup-Routine • Manche Komponenten funktionieren nicht „standalone“, sondern erfordern Konfiguration der Umgebung • Erstellen von Datenbanken • Setup von Message Queues • Komponenten können selbst Code enthalten, der bei ihrer (De-)Installation ausgeführt wird

  45. Die Custom Installer-Klasse • Eine Custom Installer-Klasse innerhalb der Komponente erbt von System.Configuration.Install.Installer • Überschreibt entsprechende Methoden, um bei der Installation Aktionen auszuführen • Install • UnInstall • Rollback

  46. Aufruf der Custom Installer -Methoden • Komandozeilen-Tool InstalUtil.exe • Custom Action innerhalb einer Microsoft Installer Package (MSI-Datei)

  47. Demo • „MySpeller“-Datenbank über InstallUtil.exe installieren

  48. Setup-Projekte mit VS .NET • Visual Studio . NET bietet gute Unterstützung der MSI-Technologie • Projekttyp „Setup Project“ • Wizard hilft bei der Erstellung • .NET-Deployment Features sind integriert • Installation von Shared Assemblies in den Global Assembly Cache • Aufruf von CustomInstaller-Methoden durch Custom Actions

  49. Vorteile der MSI-Technologie • Transaktionsbasierte Installation • „Alles oder nichts“ • Saubere Deinstallation • Logging • Unterstützung von Installationsmodi • „Vollständig“, „Typisch“, „Benutzerdefiniert“ • Dritthersteller-Tool (InstallShield, WISE) wird benötigt • Konfigurierbare Benutzeroberfläche

  50. Demo • MSI-Paket für „MyOffice“ mit Visual Studio .NET erstellen

More Related