530 likes | 675 Views
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
E N D
Deployment und Versioning von .NET Applikationen Uwe Baumann TechnologieberaterDeveloper GroupMicrosoft GmbH uwebaum@microsoft.com
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
Anforderungen [1/3] • Unkompliziertes Deployment • "XCopy"-Installation • Einfaches physikalisches Verschieben von Applikationen • Verhinderung von "Nebenwirkungen" • Neue Applikationen sollen bereits installierte Applikationen nicht negativ beeinflussen
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?
Anforderungen [3/3] • Einfache Installation von benötigten Ressourcen • Erstellen von Datenbanken • Setup von Message Queues
"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
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
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
…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
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
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
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
Demo • "MySpeller" im MSIIL Disassembler ILDasm.exe
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
Demo • Erstellung einer Multi File Assembly
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)
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
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?
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
Hash-Wert Strong Names [2/3] Public Key Metadaten Manifest Private Key + .snk File MSIL Code (kompiliert) RSA Signatur MySpeller.DLL Assembly MySpeller
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
Demo • Der Global Assembly Cache (GAC)
.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!
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!
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?
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
Konfigurationsfiles editieren • „Per Hand“ mit Notepad • Mit PlugIns der Management-Konsole • Windows XP: Systemsteuerung Verwaltung .NET Framework Konfiguration
Deployment Szenario 1 • Einfaches XCopy Deployment • Alle Files von MyOffice sollen in ein Applikationsverzeichnis
Deployment Szenario 1 C:\PROGRAMME\MYOFFICE C:\WINNT\ASSEMBLY MyCalc.EXE MyText.EXE XCOPY MySpeller.DLL C:\PROGRAMME\MYOFFICE\TOOLS Global Assembly Cache Applikationsverzeichnis
Demo • Deployment von „MyOffice“ per XCopy
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
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
Demo • Verschieben der Komponente „MySpeller“
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
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
Demo • Signieren von „MySpeller“ und Installation im Global Assembly Cache
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"
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
Demo • Deployment der neuen Version von „MySpeller“ und Konfiguration der Client-Applikationen
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")
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
Demo • „MyCalc“ zur Verwendung der vorherigen Version von „MySpeller“ zwingen
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
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
Aufruf der Custom Installer -Methoden • Komandozeilen-Tool InstalUtil.exe • Custom Action innerhalb einer Microsoft Installer Package (MSI-Datei)
Demo • „MySpeller“-Datenbank über InstallUtil.exe installieren
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
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
Demo • MSI-Paket für „MyOffice“ mit Visual Studio .NET erstellen