Laden...

Eigenes Verzeichnis oder GAC für eigene DLLS?

Erstellt von Jacyrio vor 7 Jahren Letzter Beitrag vor 7 Jahren 1.318 Views
J
Jacyrio Themenstarter:in
197 Beiträge seit 2006
vor 7 Jahren
Eigenes Verzeichnis oder GAC für eigene DLLS?

Guten Morgen,

vielleicht kann jemand von euch mir "etwas Licht ins dunkle" bringen.
Ich arbeite im Moment etwas "intensiver" mit DLLs und würde gerne einen Punkt verstehen. Ich bin da jetzt schon ein paar Tage dran am arbeiten bzw. die Antwort zu finden, da es sich aber glaube ich um eine "etwas spezielleres" Sezanrio handelt, finde ich dazu keine Antwort..

Erklärung:
Die DLLs die ich programmiere sind überwiegend für ein ERP-Systems. Das ERP-System basiert auf Access und VBA-Programmierung. Also muss ich teilweise DLLs in Access zur Verfügung stellen.

Da ich die DLLs in verschiedenen Modulen verwenden möchte, war meine Idee einen Ordner auf dem Computer zu erstellen (als Bespiel C:\MyAssemblies) indem alle meine DLLs liegen.

Die Access-Datei liegt an einer anderen Stelle (Als Beispiel C:\Programme\ERP\Module).

Jetzt mein Problem:
Sobald ich die DLL in dem Access-Modul benutze, erhalte ich den Fehler "Assembly konnte nicht gefunden werden". Nach meinen Recherchen habe ich dann heraus gefunden das es einen Global Assembly Cache gibt. Sobald ich die DLL dort installiere funktioniert das Programm.

Was mich wundert:
Auch das ERP-System ist bereits so aufgebaut. Es gibt einen Ordner (C:\Progamme\ERP\Shared) indem die ganzen DLLs liegen und einen Ordner (C:\Programme\ERP\AddIns\Works) indem die ganzen Access-Module liegen, die auf die DLLs zugreifen. Ich habe mir den GAC angeschaut.. dort ist keine dieser DLLs registriert.

Nun Frage ich mich natürlich.. wieso funktioniert das bei mir nicht? Wieso muss ich die DLLs in dem GAC installieren oder habe ich irgendwas an den DLLs-Einstellungen falsch? Ich kann jetzt hier leider nicht alle meine Einstellungen posten.. deswegen hoffe ich, dass jemand schon mal so ein ähnliches Problem hatte und mir einen Tipp geben kann.

Falls ihr noch eine Frage habt um das Problem besser zu verstehen stellt mir gerne die Frage.. ich weiß leider nicht, wie ich das Problem besser erklären kann.

MfG Jac

16.807 Beiträge seit 2008
vor 7 Jahren

Mich wundert ein wenig, dass Du erst nach 10 Jahren+ mitbekommst, dass es einen GAC gibt; aber sei es drum.
Das ist jedenfalls im Rahmen des .NET Framework die wichtigste Stelle für systemweite DLLs. (Bei .NET Core wird es - nur als Info - keinen GAC geben. Aber .NET Core ist kein Ersatz sondern steht im Stack neben dem .NET Framework.

Standardmäßig müssen DLLs bei .NET Applikationen im bin\ Ordner liegen, oder im GAC registriert sein.
Ansonsten findet sie einfach Deine .NET Istanz nicht. Es sollte logisch sein, dass DLLs nicht irgendwo liegen können. Du kannst auch nicht sagen "öffne die Test.txt" ohne den Pfad anzugeben.

Wenn Du ein wenig nach "c# custom dll path" gegoggelt hättest, dann solltest Du auf das Assembly Binding gestoßen sein.
Es gibt zwei Varianten:

Die App.Config

<configuration>
  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <probing privatePath="bin\MeinOrdner" />
    </assemblyBinding>
  </runtime>
</configuration>

sowie via Code.

AppDomain.CurrentDomain.AppendPrivatePath(@"bin\MeinOrdner");

Mehr findest Du, wenn Du Dir die dazugehörigen Basics durchliest, das Du auf alle Fälle tun solltest.

Dein ERP System wird aber mit Sicherheit ein Pluginsystem verwenden und dabei auf Lazy Binding setzen; beim kompilieren kennt also Deine Anwendung die DLLs gar nicht, sondern werden erst zu Laufzeit geladen.
Und da ist dann das AssemblyBinding eher so, dass man via Directory.EnumerateFiles die DLLs sucht, schaut, ob dort ein bestimmtes Interface existiert und wenn ja, dynamisch via Assembly.LoadFromFile geladen wird. Ein Pluginsystem eben.