Bonn-to-code.net 24.11.2009 Thomas van Veen Website:

Präsentation zum Thema: "Bonn-to-code.net 24.11.2009 Thomas van Veen Website:"—  Präsentation transkript:

1 bonn-to-code.net 24.11.2009 Thomas van Veen Email: Thomas.vanVeen@gmx.netThomas.vanVeen@gmx.net Website: http://specialworkdotnet.spaces.live.com/http://specialworkdotnet.spaces.live.com/

2 bonn-to-code.net

3 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 xy entwicklet 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 bonn-to-code.net 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 bonn-to-code.net 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 bonn-to-code.net 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 bonn-to-code.net 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 bonn-to-code.net Private Assemblies werden immer vom Anwendungs- verzeichnis geladen. Private Assemblies sollten nicht signiert werden! 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. ngen install ($TargetPath = anwendung.exe) Fazit: 1. In Produktordner kopieren 2. Nicht signieren wenn nicht unbedingt erforderlich 3. GAC Referenzen als Merge Module ausliefern oder voraussetzen. 4. Natives Images erstellen

9 bonn-to-code.net 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. ngen install ($TargetPath = anwendung.exe) ngen uninstall ($TargetName = identity) Fazit: 1. Anwendung und private Assemblies in Produktordner kopieren 2. Globale Assemblies immer signieren 3. Globale Assemblies in CodeBase-Ordner kopieren und anschießend in den GAC installieren 4. GAC Referenzen als Merge Module ausliefern oder voraussetzen. 5. Natives Images erstellen

10 bonn-to-code.net Vielen Dank für eure Aufmerksamkeit Thomas.vanVeen@gmx.net