Laden...

DLL mit Strong Name

Erstellt von plongo vor 18 Jahren Letzter Beitrag vor 18 Jahren 1.542 Views
P
plongo Themenstarter:in
123 Beiträge seit 2006
vor 18 Jahren
DLL mit Strong Name

Hallo,

ich habe vorlangen mir eine Library erstellt. Wo ich immer wieder verwenden Funktionen habe. Diese DLL's habe ich mit Strongs-Name versehen, da ich diese global nutzen möchte und nicht immer für jede WebApp. Also uberwiegend habe ich diese DLL's für meine WebApp genutzt.

Diese DLL's habe ich im GAC registriert und in der machine.config noch folgende Einträge vorgenommen.


	<compilation>
		<assemblies>
			<add assembly="Access.Database, Version=1.0.0.0, Culture=neutral, PublicKeyToken=b1f446bd6e429c9a"/>
			<add assembly="Library.Database, Version=1.0.0.0, Culture=neutral, PublicKeyToken=5c6f0310e24a82eb"/>
			<add assembly="Library.Email, Version=1.0.0.0, Culture=neutral, PublicKeyToken=2c1fdb194a90b89f"/>
			<add assembly="Library.Err, Version=1.0.0.0, Culture=neutral, PublicKeyToken=41fe72975bc7421a"/>
			<add assembly="Library.General, Version=1.0.0.0, Culture=neutral, PublicKeyToken=50ced89d05ce2679"/>
			<add assembly="Library.Page, Version=1.0.0.0, Culture=neutral, PublicKeyToken=405c214068954334"/>
			<add assembly="Library.Security, Version=1.0.0.0, Culture=neutral, PublicKeyToken=5eb92d3fe2c8c980"/>
		</assemblies>
	</compilation>

Somit kann ich wunderbar auf die DLL's zurückgreifen.

Jetzt möchte ich einige dieser DLL's auch für meine WinApp nutzen. Ich arbeite hier mit VS.NET 2005. Somit habe ich einfach ein Verweiss auf diese DLL's gemacht. Klar die notwendigen DLL's liegen im bin Verzeichniss der Applikation.

Muss ich jetzt noch diese DLL'S in der app.config registrieren? Oder geht dies auch ohne diese Registrierung?

Danke

Gruss plongo


Woher soll ich wissen, was ich denke, bevor ich höre, was ich sage!
Kurzum: Läufer sind gesünder, "gescheiter" und glücklicher als Nichtläufer.
www.andreas-nicole.de

P
plongo Themenstarter:in
123 Beiträge seit 2006
vor 18 Jahren

Keine ne Ahnung?

Danke

Gruss plongo


Woher soll ich wissen, was ich denke, bevor ich höre, was ich sage!
Kurzum: Läufer sind gesünder, "gescheiter" und glücklicher als Nichtläufer.
www.andreas-nicole.de

S
1.047 Beiträge seit 2005
vor 18 Jahren

ich hätte es einfach mal ausprobiert^^

aber ich sag mal nein, denn die runtime sucht automatisch im gac nach einer assembly die sie im aktuellen verzeichnis nicht finden kann...

wo genau zuerst gesucht wird steht bei microsoft.com... hab leider keine link zur hand 😕

muß man diese registrierungen bei asp.net anwendungen wirklich machen?

ah, hab grad das hier gefunden

When an ASPX page is compiled which includes a custom control, the compiler will not look in the Global Assembly Cache (GAC) for the shared assembly, even though your project has a reference to it.

daher brauchst du die config datei.

naja bei winforms is das net notwendig.

P
plongo Themenstarter:in
123 Beiträge seit 2006
vor 18 Jahren

Dankle für deine Antwort.

In meinen WebApp habe ich dies im GAC. Das ist klar das ich dich auch in der Config registrieren muss.

Aber in meine WinApp lege ich die direkt ins bin Verzeichniss. Da mächte ich diese nicht vorher ins GAC laden. Zu aufwändig und problematisch wenn ich mal das Programm wo anders einsetzen möchten. Dann müsste ich diese DLL's ja vorher erst ins GAC laden.

Deshalb war meine Frage wenn ich ein Verweis auf die DLL's, ob ich dann explicit auch in der config (siehe oben) registrieren muss, oder gehst dies auch ohne. Also in der app.config.

Aber muss ich nicht. Prima!

Gruss plongo


Woher soll ich wissen, was ich denke, bevor ich höre, was ich sage!
Kurzum: Läufer sind gesünder, "gescheiter" und glücklicher als Nichtläufer.
www.andreas-nicole.de

S
1.047 Beiträge seit 2005
vor 18 Jahren

ja, wie gesagt, er sucht u.a. im gleichen verzeichnis wie die exe, im gac und glaub im system32 verzeichnis danach... hatte mal nen link da stand genau wo er zuerst nachschaut aber find das net mehr 😕

hab grad in der hilfe was gefunden 🙂

ms-help://MS.VSCC.v80/MS.MSDN.v80/MS.VisualStudio.v80.de/dv_fxdeploy/html/772ac6f4-64d2-4cfb-92fd-58096dcd6c34.htm

zwar bissl lang, aber naja =)

Um Ihre .NET Framework-Anwendung erfolgreich bereitstellen zu können, müssen Sie mit dem Verfahren vertraut sein, mit dem die Common Language Runtime die Assemblys sucht und bindet, aus denen Ihre Anwendung zusammengesetzt ist. Standardmäßig versucht die Common Language Runtime, die genaue Version einer Assembly einzubinden, mit der die Anwendung erstellt wurde. Dieses Standardverhalten kann durch Einstellungen in der Konfigurationsdatei überschrieben werden.

Die Common Language Runtime führt mehrere Schritte aus, um eine Assembly zu finden und einen Verweis auf eine Assembly aufzulösen. Jeder Schritt wird in den folgenden Abschnitten erläutert. Der Begriff "Überprüfung" wird häufig verwendet, um zu beschreiben, wie die Common Language Runtime nach Assemblys sucht. Er verweist auf einige Heuristiken, mit denen die Assembly auf Basis ihres Namens und ihrer Kultur gesucht wird.

Hinweis
Bindungsinformationen können in der Protokolldatei mit dem Assembly Binding Log Viewer-Tool (Fuslogvw.exe) angezeigt werden, das im .NET Framework SDK enthalten ist.

Initiieren der Bindung
Das Auffinden einer und Binden an eine Assembly beginnt mit dem Versuch der Common Language Runtime, einen Verweis auf eine andere Assembly aufzulösen. Dieser Verweis kann statisch oder dynamisch sein. Der Compiler zeichnet statische Verweise in den Metadaten des Assemblymanifests während der Erstellungszeit auf. Dynamische Verweise werden dynamisch erstellt und resultieren aus dem Aufruf verschiedener Methoden, z. B. System.Reflection.Assembly.Load.

Der bevorzugte Weg zum Verweisen auf eine Assembly ist die Verwendung eines vollständigen Verweises mit Assemblynamen, -version, -kultur und Token des öffentlichen Schlüssels (falls vorhanden). Diese Informationen werden von der Common Language Runtime bei der Suche nach der Assembly verwendet. Die dabei ausgeführten Schritte werden in diesem Abschnitt weiter unten beschrieben. Der verwendete Auflösungsprozess ist immer gleich, unabhängig davon, ob der Verweis sich auf eine statische oder dynamische Assembly bezieht.

Sie können auch dynamisch auf eine Assembly verweisen, indem Sie die Methode nur unter Angabe partieller Informationen zur Assembly, z. B. des Assemblynamens, aufrufen. In diesem Fall wird lediglich das Anwendungsverzeichnis nach der Assembly durchsucht; es erfolgen keine weiteren Überprüfungen. Einen partiellen Verweis können Sie mit allen verschiedenen Methoden, die es zum Laden von Assemblys gibt, erstellen, etwa mit System.Reflection.Assembly.Load oder System.AppDomain.Load.

Mit einer Methode wie der System.Reflection.Assembly.Load-Methode können Sie schließlich auch dynamische Verweise erstellen und nur partielle Informationen angeben. Dann können Sie den Verweis mit dem <qualifyAssembly>-Element in der Anwendungskonfigurationsdatei kennzeichnen. Mit diesem Element können Sie die vollständigen Verweisinformationen (Name, Version, Kultur und ggf. das Token des öffentlichen Schlüssels) in der Anwendungskonfigurationsdatei anstelle im Code bereitstellen. Dieses Verfahren sollten Sie anwenden, wenn Sie einen Verweis auf eine Assembly außerhalb des Anwendungsverzeichnisses voll kennzeichnen oder auf eine Assembly im globalen Assemblycache verweisen möchten, aber gleichzeitig aus praktischen Gründen den vollständigen Verweis in der Konfigurationsdatei statt im Code angeben möchten.

Hinweis
Diesen Typ des partiellen Verweises sollten Sie nicht bei Assemblys verwenden, die für mehrere Anwendungen freigegeben sind. Da Konfigurationseinstellungen nach Anwendung und nicht nach Assembly erfolgen, müssten bei einer freigegebenen Assembly mit diesem Typ des partiellen Verweises jede Anwendung, die diese freigegebene Assembly verwendet, in der Konfigurationsdatei die kennzeichnenden Informationen enthalten sein.

Folgende Schritte werden ausgeführt, um einen Verweis auf eine Assembly aufzulösen:

Bestimmen der korrekten Assemblyversion durch Überprüfung anwendbarer Konfigurationsdateien, einschließlich der Konfigurationsdatei der Anwendung, der Herausgeberrichtliniendatei und der Computerkonfigurationsdatei. Wenn die Konfigurationsdatei auf einem Remotecomputer gespeichert ist, muss zuerst die Konfigurationsdatei der Anwendung gesucht und gedownloadet werden.

Überprüfen, ob der Assemblyname bereits zuvor gebunden wurde. Ist dies der Fall, wird die zuvor geladene Assembly verwendet.

Durchsuchen des globalen Assemblycaches. Wird die Assembly dort gefunden, wird sie von der Common Language Runtime verwendet.

Suchen der Assembly, wobei folgendermaßen vorgegangen wird:

Wenn die Konfigurations- und Herausgeberrichtlinien keine Auswirkungen auf den ursprünglichen Verweis haben und die Anforderung zur Bindung mithilfe der Assembly.LoadFrom-Methode erstellt wurde, wird nach Hinweisen auf den Speicherort gesucht.

Wenn eine CodeBase in den Konfigurationsdateien gefunden wurde, wird nur diese Position überprüft. Wenn die Überprüfung fehlschlägt, wird durch die Common Language Runtime festgelegt, dass die Anforderung zur Bindung fehlgeschlagen ist und keine weitere Überprüfung erfolgt.

Überprüfen der Assembly mithilfe von Heuristiken, die im Abschnitt Sondieren beschrieben werden. Wurde die Assembly nach der Überprüfung nicht gefunden, fordert die Common Language Runtime Windows Installer auf, die Assembly zur Verfügung zu stellen. Dabei handelt es sich um eine Installation bei Bedarf.

Hinweis
Es findet weder eine Versionsüberprüfung von Assemblys mit starkem Namen statt, noch überprüft die Common Language Runtime den globalen Assemblycache nach Assemblys ohne starken Namen.

P
plongo Themenstarter:in
123 Beiträge seit 2006
vor 18 Jahren

WOW super danke für deine Bemühung! 😁 👍

Gruss plongo


Woher soll ich wissen, was ich denke, bevor ich höre, was ich sage!
Kurzum: Läufer sind gesünder, "gescheiter" und glücklicher als Nichtläufer.
www.andreas-nicole.de