Beliebte Open-Source-Bibliotheken und Referenzkonflikte

8

Wir verwenden log4net in all unseren (vielen) internen Anwendungen. Normalerweise machen wir die xcopy-Bereitstellung. Aus praktischen Gründen haben wir die log4net-Quelle in eine unserer Kernbibliotheken übersetzt.

Das kommt jetzt zurück, um uns zu beißen. Andere Open-Source-Bibliotheken (z. B. Topshelf ) verweisen auf log4net. Wieder andere (zB NServiceBus ) führen log4net in ihre Assemblies ein. Normalerweise unterscheiden sich die Versionen.

Dies ist eine allgemeine Frage. Die spezifischen Bibliotheken sind nur Beispiele.

Es gibt mehrere ähnliche Fragen:

Von den verschiedenen Lösungen (GAC, AssemblyBinding, BindingRedirect, etc.), was wird uns wahrscheinlich die geringsten Schmerzen in der Zukunft bereiten? Wir können unsere Kernbibliothek ändern; wir können einfach nichts tun, was eine existierende Version im Feld zerstören würde. Die Aktualisierung all unserer Projektreferenzen wird schmerzhaft sein, deshalb wollen wir das nur einmal tun.

Update: Die aktuelle Version von Topshelf abstrahierte Protokollierung, das ist also kein Problem mehr mit diesem Framework.

    
TrueWill 17.11.2011, 22:21
quelle

3 Antworten

1

In Ihrem Fall würde ich meine DLL mit einer Publisher-Assembly im GAC bereitstellen Richtlinie

Eine Publisher-Richtlinienassembly ist eine Assembly, die die zu verwendende Richtlinie konfiguriert, wenn die .NET-Laufzeitumgebung an eine Assembly gebunden wird. So können Sie ganz einfach Ihr gesamtes Projekt aktualisieren, indem Sie in der Publisher-Richtlinie angeben, welche Version Ihrer DLL verwendet werden soll.

Beispiel einer Publisher-Assembly-Richtlinie:

%Vor%     
Steven Muhr 25.11.2011, 14:49
quelle
1

Ein wenig bekanntes / verwendetes Feature, das ich ständig mit mehreren Referenzen zu tun habe, und das einfach zu aktualisieren ist, ist Referenzpfade in Kombination mit Binding Redirects. Mithilfe von Referenzpfaden kann ich eine gemeinsame Bibliothek in einer separaten Klassenbibliothek / einem Paket in der Quellcodeverwaltung verwalten, die die abhängige Bibliothek enthält, die wir verwenden.

Wenn ich meine eigene Kopie der Dateien separat steuern lasse (oft muss eine Datei .license in den Ordner für gemeinsam genutzte Bibliotheken eingefügt werden, wenn es sich um eine kostenpflichtige Bibliothek handelt), können neue Entwickler sie schnell sichern haben die richtige Version auf ihrem Computer installiert, ohne mit den vorhandenen Bibliotheken zu kollidieren, die sich bereits auf Ihrem Computer befinden.

Es gibt eine Einschränkung für diesen Ansatz, und das bedeutet, dass zusätzliche Referenzpfade, die Sie hinzufügen, nicht in der Datei .csproj gespeichert werden, sondern stattdessen in .csproj.user Datei.

In vielen sofort einsatzbereiten Versionskontrolllösungen wie Team Foundation Server oder Vault; Diese Dateien sind standardmäßig nicht im Eincheckvorgang enthalten. Die meisten Anbieter von Quellcodeverwaltung, einschließlich der beiden genannten, verfügen jedoch über eine Option zum Ändern der kontrollierten Dateierweiterungen pro Projekt sowie global.

Der einzige andere Nachteil ist, dass einige Quellcodeverwaltungsanbieter wie Vault die Dateien .csproj und .csproj.user standardmäßig als Binärdateien behandeln. Auch dies kann geändert werden, und sie können im Fall von Vault als XML behandelt werden, wodurch Zusammenführungen möglich sind.

Sie werden in Team Foundation Server als XML out-of-box behandelt.

    
Brian Deragon 21.11.2011 20:42
quelle
0

Es gibt einen NServiceBus, der keine Assemblies von Drittanbietern zusammenführt.

Von der Download-Seite :

  

Probleme mit zusammengeführten Baugruppen?

     

Um die Anzahl der Assemblies zu reduzieren, die Entwickler in ihren Visual Studio-Projekten referenzieren müssen, führt NServiceBus mehrere Assemblies von Drittanbietern in seine eigenen Assemblys zusammen. Dies kann zu Konflikten führen, wenn Entwickler diese Assemblys von Drittanbietern in ihrem eigenen Code verwenden, insbesondere wenn sie eine andere als die mit NServiceBus gelieferte Version verwenden.

     

Um dieses Problem zu beheben, sollten Entwickler die Nur-Core-Assemblys von NServiceBus verwenden. Für Unternehmen, die ein kommerzielles NServiceBus-Lizenz- und Support-Paket erworben haben, befinden sich diese Assemblys im Verzeichnis "core-only".

     

Wenn Sie die Express Edition verwenden, müssen Sie die Quelle (oben) herunterziehen und sie selbst mit der Datei "UnsupportedBuildCoreOnly.bat" kompilieren.

    
Craig Stuntz 17.11.2011 22:30
quelle

Tags und Links