Deployment und Versioning von .NET Applikationen MSDN TechTalk – Mai 2002 Deployment und Versioning von .NET Applikationen 1 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 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

Ein Beispielprojekt: "MyOffice .NET"

"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

VS.NET: Assembly-Referenzen "Add Reference"-Dialog: Eintrag in der Registry nötig Siehe auch KB-Artikel Q306149 [HKEY_CURRENT_USER \SOFTWARE\Microsoft\.NETFramework\AssemblyFolders \<MyAssemblies>] @="C:\\<MyAssemblies>"

"MyOffice" - Abhängigkeiten Applikations-Komponenten (Lokaler Speicherort) Gemeinsame Systemkomponenten (Zentraler Speicherort) MyCalc.EXE System.Windows.Forms.DLL .NET Formularbibliothek NEUE VERSION! MyText.EXE MSCorLib.DLL .NET Basis-Datentypen NEUE VERSION! 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

Inside "MySpeller" Jedes Modul enthält… 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 Metadaten Reference-Tabellen  Was wird importiert? Definition-Tabellen  Was wird exportiert? 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) 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 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

Assembly MySpeller Version X 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 Metadaten Importe Manifest Exporte Files Exporte MSIL Code (kompiliert) MySpeller.DLL Assembly MySpeller Version X

Demo "MySpeller" im MSIIL Disassembler ILDasm.exe

Multi File Assembly Assembly MySpeller Version X Metadaten Importe Manifest Files Exporte Metadaten Importe Exporte Metadaten Importe 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

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

Strong Names [3/3]  + A=B ? Public Key Metadaten Manifest 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:\WINNT\ASSEMBLY C:\PROGRAMME\MYOFFICE 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:\WINNT\ASSEMBLY C:\PROGRAMME\MYOFFICE MyText.EXE MyCalc.EXE Wo ist MySpeller? MySpeller.DLL MyText.EXE .config <?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:\WINNT\ASSEMBLY C:\PROGRAMME\MYOFFICE MySpeller.DLL MyText.EXE MyCalc.EXE MyText.EXE .config Wo ist MySpeller? 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:\WINNT\ASSEMBLY C:\PROGRAMME\MYOFFICE 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:\WINNT\ASSEMBLY C:\PROGRAMME\MYOFFICE 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 integrierter Setup-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

Deployment der Runtime [1/2] Windows .NET Server enthält als erstes Betriebssystem die .NET Runtime Für alle anderen Systeme ab Windows 98 kann die .NET Runtime separat installiert werden

Deployment der Runtime [2/2] Standalone Executable: DotNetFx.EXE Ca. 21 MB groß, installiert komplette Runtime DotNetFx.EXE kann per Bootstrapper installiert werden (silent mode) Siehe http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetdep/html/vsredistdeploy.asp

Vielen Dank! Fragen kostet nichts…