.Net Assemblies optimal installieren und beschleunigen

1. 24.11.2009 Thomas van Veen .Net Assemblies optimal installierenund beschleunigen Email:Thomas.vanVeen@gmx.net Website:http://specialworkdotnet.spaces.live.com/

2. Aufbau eines „Global Static Single Module“ Assembly

3. Ein paar Grundlagen zu Assemblies • Assembly • Eine Assembly ist eine Anwendung bzw. Bibliothek die speziell für das .Net Framework entwickelt wurde. Sie besteht aus einem Manifest und mindestens einem Modul. Assemblies sind nur auf Betriebssystemen ausführbar, auf dem eine kompatible .Net Runtime installiert ist (z.B. Windows mit .Net Framework oder Linux mit Mono). • Manifest • Das Manifest enthält Informationen wie z.B. die Assemblyidentität, die Signatur, oder die Basisadresse einer Assembly sowie alle nötigen Informationen zu den referenzierten Assemblies. • Modul • Das Modul enthält wiederum verschiedene Typen dessen Strukturen in den Metadaten beschrieben sind. Module können mit Hilfe eines .Net Compilers (z.B. csc.exe) erzeugt und im Dateisystem abgelegt werden. Module können jedoch nicht ausgeführt bzw. von Assemblies referenziert werden. • Assemblyidentität • Die Assemblyidentität ist ein Text bestehend aus der Versionsnummer, dem Displaynamen und Informationen zur Kultur. Ist eine Assembly signiert, wird außerdem noch der Public Key der Signatur mit ausgegeben. In diesem Fall spricht man von einem „Strong Name“ oder einer „Strong Named“ Assembly. • Signatur (Key) • Die Signatur besteht aus einem Private- und einem Public Key. Mit Hilfe der Signatur wird die Herkunft der Assembly eindeutig festgelegt und damit sichergestellt, dass diese Assembly vom Hersteller xyentwicklet und vertrieben wurde. Solche Key-Files kann man sich selbst mit Hilfe des Kommandozeilentools „sn.exe“ (sn –k „keyfile.snk“) erstellen. Alternativ können solche Signaturen auch noch von z.B. Verisign (kostet aber jährlich) validiert und signiert werden. • Metadaten • Die Metadaten sind Bestandteil von Modulen und beschreiben alle Typen (auch private und internal) die in der Assembly enthalten sind. Die Metadaten sind vergleichbar mit einer Typelibrary (.tlb) aus der COM-Welt. • Typen im MSIL Code • Die Typen selbst beinhalten den eigentlichen Quellcode im MSIL Format (Microsoft Intermediate Language).

4. Verschiedene Assembly Typen • Single Module Assembly • Ein Single Module Assembly ist eine Assembly welches aus nur einem Modul aufgebaut ist. Sie ist die am häufigsten verbreitete Form. • Multi Module Assembly • Ein Multi Module Assembly hingegen unterscheidet sich nur in der Anzahl der integrierten Module. Diese Art der Assembly kann man nicht mit Visual Studio erzeugen. Es ist jedoch möglich eine solche Assembly mit Hilfe des Kommandozeilen Compilers „csc.exe“ zu erstellen. • Statische Assemblies • Eine statische Assembly wird von einem Compiler erzeugt, im Dateisystem abgelegt und anschließend ausgeführt bzw. von anderen Assemblies referenziert. Statische Assemblies sind am häufigsten verbreitet. • Dynamische Assemblies • Dynamische Assemblies werden zur Laufzeit erzeugt. Hierzu wird ein Quelltext z.B. mit Hilfe des Code Dom Compilers kompiliert und somit „in Memory“ eine Assembly erzeugt und ausgeführt. Der Nachteil, oder auch Vorteil ist, dass diese Assemblies meist temporär existieren. Es ist allerdings auch möglich diese Assemblies im Dateisystem abzulegen, womit diese dann wieder Statische Assemblies wären. • Private Assemblies • Private Assemblies sind Assemblies die von nur einer Anwendung verwendet bzw. referenziert werden (können). Das bedeutet, dass diese Assemblies meist im gleichen oder im Unterverzeichnis der aufrufenden Anwendung liegen. Dies ist die häufigste Form der Verbreitung von .Net Anwendungen. • Globale Assemblies • Globale Assemblies unterscheiden sich in mehreren Punkten von den privaten Assemblies. Zum einen besitzen sie einen sogenannten „Strong Name“ in ihrem Manifest. Zum zweiten sind Globale Assemblies aber erst dann Globale Assemblies, wenn sie auch im Global Assembly Cache (GAC) installiert wurden. Globale Assemblies können keine privaten Assemblies referenzieren.

5. Wichtige Tools • gacutil.exe • C:\Program Files\Microsoft SDKs\Windows\v7.0A\bin\gacutil.exe • Zeigt den Inhalt des Global Assembly Cache (GAC). Installiert bzw. deinstalliert Assemblies im GAC. Dummerweise ist dieses Tool nicht im Toolset der .Net Runtime enthalten sondern nur im Windows SDK. • ngen.exe • C:\Windows\Microsoft.NET\Framework\v2.0.50727\ngen.exe • Zeigt den Inhalt des Cache für Native Assemblies (ZAP). Ngen kompiliert Assemblies mit Hilfe des „Just in Time Compilers (Jit)“ und erzeugt ein natives Image, welches dann im ZAP installiert wird. Dieses Tool wird mit der .Net Runtime ausgeliefert. • sn.exe • C:\Program Files\Microsoft SDKs\Windows\v7.0A\bin\sn.exe • Erzeugt eine Datei in der das sogenannte Schlüsselpaar (Private- und Public Key) enthalten ist, die für die Signierung eines Assemblies benötigt wird. • Microsoft .NET Framework 2.0-Konfiguration • C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\Bin\mscorcfg.msc • Mit Hilfe dieses MMC Snap-In kann man sich den Inhalt des GAC sowie des ZAP anzeigen lassen, Assemblies konfigurieren, installieren und deinstallieren, aber leider nicht jitten. Dieses Snap-In ist nur mit dem Windows SDK verfügbar. • Windows Explorer • C:\Windows\Assembly\ • Der Windows Explorer bietet mit dem Fusion-Addin eine Alternative zum vorherigen MMC-Snap-In. Öffnet man im Windows Explorer den Pfad „C:\Windows\Assembly\“ so wird einem der Inhalt des GAC präsentiert. Auch hier kann man Assemblies installieren bzw. deinstallieren, usw. • Ildasm.exe • C:\Program Files\Microsoft SDKs\Windows\v7.0A\bin\NETFX 4.0 Tools\ildasm.exe • Mit diesem Tool kann man sich z.B. das Manifest einer Assembly anzeigen lassen, Assemblies disassemblieren, u.v.m.. (Enthalten im Windows SDK) • Process Explorer • Diese Tool hilft bei der Ermittlung der Einsprungsadressen von Assemblies. (früher SysInternals) • regedit.exe • C:\Windows\regedit.exe • Dieses Tool dürfte wohl jedem bekannt sein.

6. Vorbereitung • Windows SDK installieren • Falls nicht schon vorhanden; runterladen, installieren, fertig. • Meist wird das SDK auch schon mit der Installation von Visual Studio installiert. • Systemvariablen setzen • Der Systemvariable System\Path folgende Pfade hinzufügen getrennt durch „;“ Semikolon. • C :\Windows\Microsoft.NET\Framework\v2.0.50727 • C:\Program Files\Microsoft SDKs\Windows\v7.0A

7. Wohin mit meinen Assemblies? • Wohin mit den Globalen Assemblies? • Generell kann man sagen, das Globale Assemblies in den Global Assembly Cache installiert werden sollten. Also praktisch alle Klassenbibliotheken, die man systemweit verfügbar machen möchte. • Die „Codebase“ • Zuerst sollte man im Ordner „Common Files“ einen entsprechenden Ordner (Common files\Hersteller\Product) erstellen, und dort alle globalen Assemblies hineinkopieren. Dies ist die sogenannte „CodeBase“, ein Ordner in dem bei späteren Updates die Assemblies überschrieben und dann im GAC bzw. ZAP aktualisiert werden können. • Custom Actions • Die Installation einer Assembly wird dann entweder mit Hilfe einer Custom Action in einem MSI Paket oder aber direkt mit dem Tool gacutil.exe durchgeführt. • Nachteil GAC • Ein Nachteil bei der Installation in den GAC ist, dass man keinen direkten Zugriff auf die „app.config“ der Assembly hat. Allerdings werden globale Assemblies schneller geladen, da eine Überprüfung der Herkunft nicht mehr notwendig ist. • Produktordner • Die Anwendung(en) (*.exe) sollten jedoch nicht im GAC sondern wie üblich unter „Programme\Hersteller\Produkt“ installiert werden. • Native Images erzeugen • „Abschließend sollten für alle Assemblies (Klassen-bibliotheken als auch Anwendungen) Native Images mit Hilfe des Tools ngen.exe erstellt werden.“ • Wohin mit meinen Privaten Assemblies? • Alle privaten Assemblies, also alle die nicht signiert wurden, sollten demnach in den Produktordner „Programme\Hersteller\Produkt“ kopiert werden. • Native Images erzeugen • „Auch bei den privaten Assemblies ist es sinnvoll, daraus Native Images zu erstellen. Sie sind aber nur dann wirklich schnell, wenn sie nicht signiert wurden.“

8. Private Assemblies verteilen • Private Assemblies werden immer vom Anwendungs- verzeichnis geladen. Private Assemblies sollten nicht signiertwerden! Der Grund dafür ist, dass solche Assemblies aufgrund der Signatur zunächst im GAC gesucht werden. Erst wenn festgestellt wird, dass sie dort nicht vorhanden sind und auch keine entsprechendes Routen in der „app. config“ festgelegt wurde, wird das lokale Verzeichnis durchsucht. Außerdem führt dies zu unerwünschten Performanceverlusten und unnötigen Seitenaufrufen im Speicher. • Ausnahme sind Anwendungen (*.exe) die eine Signatur für ein Deployment Scenario (z.B. ClickOnce) benötigen. Anwendungen die signiert sind, werden trotz der Signatur sofort aus dem Dateisystem gestartet. • Alle Assemblies die von einer „Privaten“ Anwendung referenziert werden, sollten demnach als lokale Kopie im gleichen bzw. in einem Unterordner abgelegt werden. • Benötigt eine private Assembly jedoch eine Assembly aus dem GAC, sollte sie weder lokal kopiert, noch mit der Anwendung verteilt werden. In diesem Fall ist es notwendig beim Deployment entsprechende Merge Module mit auszuliefern, bzw. vorauszusetzen, das die entsprechende Anwendung auf dem Zielsystem installiert ist (.z.B: .Net Framework, oder verschiedene Primary Interop Assemblies). • Private Assemblies sollten während oder nach der Installation mit Hilfe des Tools „ngen.exe“ in ein Natives Image kompiliert werden. • Der folgende Aufruf erzeugt ein natives Image der „privaten“ Anwendung. • ngeninstall „($TargetPath = anwendung.exe)“ • Fazit: • In Produktordner kopieren • Nicht signieren wenn nicht unbedingt erforderlich • GAC Referenzen als Merge Module ausliefern oder voraussetzen. • Natives Images erstellen

9. Globale Assemblies verteilen • Globale Assemblies sollte man dann im GAC installieren, wenn man die darin enthaltenen Typen systemweit verfügbar machen möchte. Signierte Assemblies sollten immer in den Global Assembly Cache installiert werden, da sie erst dann systemweit verfügbar sind. Aufgrund ihrer Signatur ist eine Installation im GAC überhaupt erst möglich. • Globale Assemblies brauchen keinen Ordner, indem sie installiert werden. Sollten sie aber!. Zum einem fällt es dem Kunden bei eventuellen Supportanfragen leichter, in einen Ordner zu wechseln um dort beispielsweise die Versionsnummer einer Assembly zu ermitteln. Zum zweiten dient ein solcher Ordner aber auch als sogenannte „Codebase“ für spätere Updates des Produktes. • Globale Assemblies werden mit Hilfe des Windows SDK Tools „gacutil.exe“ in den GAC installiert. Auch hier ist eine Installation mit Hilfe einer Custom Action ratsam. • Der folgende Aufruf installiert bzw. deinstalliert eine Globale Assembly in den Global Assembly Cache (GAC). • gacutil /i „($TargetPath = anwendung.exe)“ • gacutil /u „($TargetName = displayname)“ • Der folgende Aufruf erzeugt ein natives Image der Anwendung. • ngeninstall „($TargetPath = anwendung.exe)“ • ngenuninstall „($TargetName = identity)“ • Fazit: • Anwendung und private Assemblies in Produktordner kopieren • Globale Assemblies immer signieren • Globale Assemblies in „CodeBase“-Ordner kopieren und anschießend in den GAC installieren • GAC Referenzen als Merge Module ausliefern oder voraussetzen. • Natives Images erstellen

10. Vielen Dank für eure Aufmerksamkeit Thomas.vanVeen@gmx.net Das Wars – Fragen?