2009-03-10 15 views
10

Ich habe C# -Anwendung, die eine DLL verwendet. Wenn ich versuche, die Anwendung auszuführen, kann sie die DLL nicht finden, es sei denn, sie befindet sich im selben Verzeichnis oder in GAC. Ich möchte es nicht im selben Verzeichnis haben und ich möchte es nicht in GAC installieren. Gibt es eine Möglichkeit, der Anwendung mitzuteilen, wo nach der Bibliothek gesucht werden soll? (Zum Beispiel, wenn ich will die Anwendung an Kunden verteilen und sie wollen ihre eigenen Anwendungen nutzen, die die DLL verwenden würde.)Wie wird der C# -Bibliothekspfad für eine Anwendung festgelegt?

Hinzugefügt:

Ich möchte diese Dateistruktur haben:

Hauptordner: Bibliotheken, Anwendungen

Bibliotheken: lib.dll

Anwendungen: App1.exe

I don‘ t möchte es nach GAC kopieren oder lib.dll im Ordner Applications haben. Ist es möglich?

+0

Tamara, ist es auch möglich, Ihre vorherige Frage zu bearbeiten. Das wäre der bevorzugte Weg. –

+0

Tamara, diese Frage ist sehr ähnlich wie diese http://stackoverflow.com/questions/629459/c-cannot-find-library-during-runtime –

Antwort

6
+0

Is'n das im Grunde das gleiche wie das Kopieren auf GAC? –

+0

Nein, sie sind konzeptionell anders. Mit dieser Methode können Sie sogar eine in GAC installierte Assembly in eine andere Version umleiten. Sie müssen die Maschinenkonfiguration bearbeiten oder die DLL in ein Unterverzeichnis stellen. Ich bezweifle, dass einer von ihnen das ist, was du willst, aber wie GvS und Jon darauf hingewiesen haben, ist das im Allgemeinen keine gute Sache –

0

Wie ich auf Ihre vorherige Frage in meiner Antwort sagte:

Verwenden Assembly Redirection Anweisungen in Ihrem app.config oder machine.config.

8

Ich würde empfehlen, dass die Anwendungen Ihrer Kunden die DLLs kopieren, die sie in ihrem eigenen Verzeichnis verwenden.

VB6 verwendet DLL zwischen Anwendungen zu teilen, haben wir einen Begriff dafür: DLL Hell

+0

+1 Große Antwort! Ich muss upvote! –

+0

Bitte verwenden Sie den moderneren Begriff für "DLL Hell" ---> Der globale Assemblycache. =) Ich denke, MS hat es gut gemeint ("Der Weg zur Hölle ist ..."), als sie den GAC gemacht haben, aber es fühlt sich an wie der alte Schmerz ... App-Seltsamkeit, fehlende Funktionen, zusätzliche Einsatzschritte usw. – StingyJack

1

Die DLL haben werden entweder im GAC oder im Anwendungsverzeichnis oder ein Unterverzeichnis sein, wie die Antworten auf Ihre frühere Frage sagte.

Wenn Ihre Kunden ihre eigenen Anwendungen mithilfe der DLL schreiben möchten, sollten Sie sie entweder im GAC installieren oder sie dazu bringen, die DLL ebenfalls zu kopieren. Mehrere Kopien der Bibliothek haben nicht Sound wie eine gute Sache, aber es ist wirklich: es bedeutet, dass Sie eine Kopie auf eine andere Version aktualisieren können, ohne alles andere zu brechen.

0

Sie können die Aktionen protokollieren und anzeigen, die das Framework beim Laden einer Assembly ausgeführt hat. Dies macht das Diagnostizieren von Montage-Ladefehlern sehr einfach.

Das Tool, beides zu tun, ist "FUSLOGVW.exe" (Fusion Log Viewer, Fusion ist der Name des Ladeprogramms) und im SDK enthalten.

4

In Ihrem Main:

AppDomain.CurrentDomain.AssemblyResolve += (s,e)=>{ 
    var filename = new AssemblyName(e.Name).Name; 
    var path = string.format(@"C:\path\to\assembly\{0}.dll", filename); 
    return Assembly.LoadFrom(path); 
}; 

eine Ausnahme hinzufügen, dass

+0

Danke ; In meinem Fall installieren alle unsere Benutzer ein spezifisches Produkt-SDK und wir wissen ungefähr, wo die Bibliothek ist. Der AssemblyResolve Event-Handler war genau das, was ich brauchte. – Epu

1

Handhabung Es ist möglich, ohne dass die GAC, aber Baugruppen müssen stark benannt sein und Sie müssen Änderungen, wenn die Version app.config machen oder publickeytoken ändert sich. Dies ist, was ich habe Hauptprogramm in \, Shared libs in \ Shared. und ein Unterprogramm, das ich in \ SDK trennen möchte, verwendet es .. \ Shared für die Assemblys.

<runtime> 
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"> 
     <probing privatePath="shared" /> 
     <dependentAssembly> 
     <assemblyIdentity name="protobuf-net" publicKeyToken="257b51d87d2e4d67" /> 
     <codeBase version="1.0.0.282" href="../protobuf-net.dll"/> 
     </dependentAssembly> 
     <dependentAssembly> 
     <assemblyIdentity name="SevenUpdate.Base" publicKeyToken="5d1aea1de74f122c" /> 
     <codeBase version="11.5.4.0" href="../SevenUpdate.Base.dll"/> 
     </dependentAssembly> 
     <dependentAssembly> 
     <assemblyIdentity name="SharpBits.Base" publicKeyToken="5d1aea1de74f122c" /> 
     <codeBase version="11.5.5.0" href="../SharpBits.Base.dll"/> 
     </dependentAssembly> 
     <dependentAssembly> 
     <assemblyIdentity name="System.Windows" publicKeyToken="5d1aea1de74f122c" /> 
     <codeBase version="11.5.5.0" href="../System.Windows.dll"/> 
     </dependentAssembly> 
     <dependentAssembly> 
     <assemblyIdentity name="WPFLocalizeExtension" publicKeyToken="5d1aea1de74f122c" /> 
     <codeBase version="11.5.5.0" href="../WPFLocalizeExtension.dll"/> 
     </dependentAssembly> 
    </assemblyBinding> 
    </runtime> 
Verwandte Themen