Package oder DLL?

[Olaf Balke]

Moin, Moin,

ich habe noch ein paar Schwierigkeiten mit selbst geschriebenen Assemblys:

Damit der Client (der das selbst geschriebene Package - wie im Delphi.NET Sonderheft beschrieben - einbindet) auch auf Rechnern ohne Entwicklungsumgebung läuft, ist es notwendig das Package im GAC abzulegen - oder ?

Dies hieße, daß das Package einen öffentlichen Schlüssel benötigt, da die "Microsoft .NET Framework 1.1-Konfiguration" sonst meckert - oder?

Dies hätte zur Folge, daß auch der Client einen öffentlichen Schlüssel benötigt, da strong names nur von strong names aufgerufen werden können - oder?

Eine weitere Frage: Wenn sich im Zuge eines Delphi 8 Updates einige Borland-Assembly's ändern, ist es sicher auch notwendig diese (sofern neue eigene Programme diese benötigen) an externe Rechener weiterzugeben - oder?
Wie aber verhalten sich dann ältere Programme, die die vorherige Version der Borland-Assembly erwarten? Denn es ist doch so, daß die erwartete VersionsNr explizit im Programm abgelegt ist - oder?

Um die Verwirrung (meine) komplett zu machen: Wenn ich in Delphi 8 eigene Assemblys einbinde, ist es dann richtig, daß ich um interne Änderungen an der eingebundenen Assembly auch im Client nutzen zu können, diesen auch jedesmal neu kompilierern muß - widersprich dies nicht dem Nutzen von eigenständigen Assemblys?

[Andreas Kosch]

Hallo,

>..ist es notwendig das Package im GAC abzulegen - oder ?

Nein - der GAC wird nur dann benötigt, wenn die externen Assembly-DLLs <b>nicht</b> im gleichen Verzeichnis wie die Anwendung liegen sollen (oder auch nicht in einem privaten Suchpfad liegen sollen). Der GAC ist der <i>Sonderfall</i>, aber nicht der Regelfall. Die einfache XCOPY-Installation geht davon aus, dass alles ins gleiche Verzeichnis bzw. wenn eine .config-Datei genutzt wird, in den gleichen Verzeichnisbaum kopiert wird.

&gt;..einen öffentlichen Schlüssel benötigt...

Ja - jede Assembly, die im GAC installiert werden soll, muss einen Strong Name (Kombination von Assembly-Name, Versionsnummer, Ländereinstellung und Key) besitzen.

&gt;..da strong names nur von strong names aufgerufen werden können ...

Dies gilt nur dann, wenn die im GAC abgelegte Assembly zusätzliche Schutzvorkehrungen gegen "missbräuchliche" Benutzer trifft. Wenn diese Annahme global zuträfe, könnte keine einzige .NET-Anwendung erfolgreich gestartet werden, die keinen Strong Name hat (denn jede .NET-Anwendung greift auf die CLR-Assemblies aus dem GAC zu).

&gt;Wie aber verhalten sich dann ältere Programme, <br>
&gt;die die vorherige Version der Borland-Assembly erwarten?

Wenn über die Policies die Versionsnummern <b>nicht</b> "umgebogen" werden, rufen die alten Clients immer nur die alten Versionsnummern auf (Side-by-Side). Erst dann, wenn in der neu angelegten *.config-Datei der alten Anwendung ein <B>bindingRedirect</b>-Eintrag untergebraucht wird oder über die <i>.NET Framework Configuration</i> die Versionsnummer global für alle bestehenden Anwendungen umgebogen wird, würde der alte Client die neuen Assembly-Versionen aufrufen.

&gt;..diesen auch jedesmal neu kompilierern muß.

Das erneute Kompilieren des Clients ist nur dann notwendig, wenn sich im Interface (genauer gesagt, den nach Außen hin öffentlich sichtbaren Teilen) etwas geändert hat. Solange sich nur die interne Implementierung ändert, bekommt der Client davon nichts mit. Wenn der Client ohne Neukompilation eine Assembly aufrufen soll, die in der neuen Fassung eine höherer Versionsnummer hat, ist dies erst dann erfolgreich, wenn die Versionsnummer entweder nur für diese Anwendung oder global für alle Anwendungen auf die neue Versionsnummer umgebogen wird. Das folgende Beispiel demonstriert dies anhand einer lokal gültigen .config-Datei:
<pre>
<pre>&lt;?xml version=&quot;1.0&quot;?&gt;
&lt;configuration&gt;
&lt;runtime&gt;
&lt;assemblyBinding xmlns=&quot;urn:schemas-microsoft-com:asm.v1&quot;&gt;
&lt;probing privatePath=&quot;Bin&quot; /&gt;
&lt;dependentAssembly&gt;
&lt;assemblyIdentity name=&quot;OSProbingDemoLib&quot; publicKeyToken=&quot;d0ac782f480cdd54&quot; culture=&quot;de-DE&quot;/&gt;
&lt;publisherPolicy apply=&quot;no&quot; /&gt;
<font color="#ff0000"> &lt;bindingRedirect oldVersion=&quot;1.2.0.0&quot; newVersion=&quot;1.3.0.0&quot; /&gt;</font>
&lt;/dependentAssembly&gt;
&lt;/assemblyBinding&gt;
&lt;/runtime&gt;
&lt;/configuration&gt;</pre>
</pre>
Diese .config-Datei legt fest, dass jeder Aufruf der DLL-Version 1.2.0.0 automatisch auf die neue Version 1.3.0.0 umgeleitet wird. Somit ruft der alte Client (der in seinem Manifest nur die Version 1.2.0.0 einbindet) beim nächsten Start die im Bin-Unterverzeichnis abgelegte neue DLL auf

[Olaf Balke]

Hallo Herr Kosch,

Vielen Dank für die schnelle (und rettende) Hilfe!!

Die automatisch hochzählende VersionNr der Assembly' s und (der daraus folgende Fehler "The located assembly' s manifest definition with name.. does not match the assembly reference" haben mich zuvor völlig durcheinander gebracht.

Man nehme: Von Hand angepasste VersionsNr ohne Strong Name, compilierte DLL und Client im gleichen Verzeichnis und schon läuft alles ohne Probleme (sowohl in der Entwicklungsumgebung als auch auf dem externen Rechner).

Und auch der <b> bindingRedirect</b>-Eintrag hört sich interessant an.

Also nochmal Vielen Dank