Ich war ein ASP.NET / WCF-Entwickler für die meisten meiner .NET-Entwicklerkarriere, deshalb bin ich sehr daran gewöhnt, dass alle DLLs im bin-Ordner des IIS-Verzeichnisses sitzen.
In einem aktuellen Projekt müssen wir jedoch mehrere DLLs (ca. 50) zwischen einem WCF-Webdienst und mehreren EXE-Programmen teilen, sodass einer unserer Teammitglieder vorgeschlagen hat, diese DLLs in den GAC zu installieren.
Ich kann mit dieser Idee nichts falsch finden, aber ich habe nur das Gefühl, dass das Installieren von Domänen-DLLs wie Datenzugriff und Geschäftslogik für ein bestimmtes Produkt in GAC falsch ist, da diese DLLs nicht wie System.Data sind wiederverwendbar über viele verschiedene Produkte.
Installieren Sie die DLLs Ihres Produkts in GAC?
Achtung, dies ist ein heiliger Kriegsbereich
Ich habe es in beide Richtungen gesehen, wenn eine DLL geteilt wird, wird sie im Allgemeinen GAC (das ist unsere einfache Faustregel). Grundsätzlich wollen wir nicht mehrere Vorkommen der gleichen DLL herumliegen. Wir umgehen diese Regel jedoch, wenn die Bibliothek instabil ist oder aka Änderungen / neue Versionen unterliegt.
Manche Leute argumentieren, dass es besser ist, sich selbst zu silozieren (Place in Bin), um zu verhindern, dass jemand eine gac'd-DLL neu installiert, die möglicherweise Ihre App zum Absturz bringen könnte. Wenn Sie eine gemeinsam genutzte Bibliothek verwenden, müssen Sie im Allgemeinen vorsichtig sein, wenn Sie Änderungen vornehmen. Wenn Sie jemanden anderen brechen wollen, möchten Sie wahrscheinlich darüber nachdenken, die Version zu inkrementieren. Dann können Sie beide Versionen auf dem GAC bereitstellen.
Ein weiteres Argument gegen das Platzieren von bin ist, wenn Sie eine neue Version installieren möchten, müssen Sie sie in N verschiedenen Orten platzieren.
Meine Voreingenommenheit zeigt sich durch meine Antwort (ich bevorzuge gac über die Duplizierung)
In den meisten Fällen legen wir keine .DLL-Anwendungen auf den GAC. Dies führt zwar zu Überschneidungen, vereinfacht jedoch die Probleme bei der Versionsverwaltung (je mehr Apps Sie haben, desto mehr werden sie sich mit unterschiedlichen Geschwindigkeiten entwickeln) härter als etwas (billigen) Speicherplatz zu verschwenden.
Ich würde sie lieber im bin-Ordner behalten - die xcopy-Bereitstellung ist viel einfacher.
Die Bereitstellung im GAC ist ein Albtraum, wenn Sie die DLLs, die Sie dort abgelegt haben, aktualisieren müssen. Was auch immer in den GAC geht, sollte ziemlich statischer, versionierbarer Inhalt sein. Andernfalls platzieren Sie nicht in den GAC .
Ein alternativer Ansatz könnte darin bestehen, die freigegebenen DLLs auf 1) einem gesicherten Intranet-Webserver oder 2) einem allgemein zugänglichen Netzwerkordner zu hosten und das AssemblyResolve (MSDN-Verknüpfung hier) , um sie zu laden. Wir machen das bei unserem aktuellen Projekt und es war sehr, sehr effektiv.
Tags und Links .net