it-swarm.com.de

Führen Bindungsumleitungen in app.config für Klassenbibliotheken zu etwas?

Die VS-Lösungen, mit denen ich häufig arbeite, bestehen aus einem single ausführbaren Projekt (Konsolen-App, Web-App) und vielen Klassenbibliothek-Projekten, auf die alle von der ausführbaren Datei verwiesen wird.

Bei der Arbeit mit NuGet und beim Installieren von Paketen wird häufig für jedes Projekt eine app.config-Datei erstellt, die in der Regel nichts anderes enthält als eine Liste von Bindungsumleitungen, die Versionen von referenzierten Assemblys konsolidieren. In manchen Fällen gibt es einige bibliotheksspezifische Inhalte von Drittanbietern (wie etwa den Entity Framework-Konfigurationsabschnitt).

Wenn ich die Lösung erstelle und die Binärdateien des ausführbaren Hauptprojekts verwende, werden in der Build-Ausgabe alle Klassenbibliothek-Projektassemblys zusammen mit den entsprechenden *.config-Dateien angezeigt (die app.config-Datei wird beim Erstellen in AssemblyName.config umbenannt).

Haben die Konfigurationsdateien der Klassenbibliotheksassemblys beim Starten der Hauptprogrammdatei Auswirkungen? Oder ist es nur die app.config-Datei der ausführbaren Datei, die in diesem Fall Auswirkungen hat? Was ist, wenn für einige Klassenbibliotheksprojekte einige verbindliche Weiterleitungen und für das ausführbare Hauptprojekt verschiedene verbindliche Weiterleitungen eingerichtet sind - wie werden diese kombiniert, die Vorrang haben?

Ich habe versucht, dies online zu recherchieren, und aus dem, was ich gelesen habe, scheint es mir, dass die app.config-Dateien für nicht ausführbare Assemblys unbrauchbar sind (in Bezug auf verbindliche Weiterleitungen). Kann jemand das bestätigen oder etwas mehr zum Thema ausarbeiten?

Wenn es so ist, ist es tatsächlich unerwünscht, dass diese app.config-Dateien von NuGet in Klassenbibliotheken erstellt werden, wenn sie nur die Bindungsumleitungen enthalten? Ich habe das Gefühl, dass NuGet keine verbindlichen Weiterleitungen für Klassenbibliothekprojekte erstellen sollte, da dies die Verwirrung darüber, welche Einstellungen tatsächlich angewendet werden, nur verstärkt.


Ich habe diese vorhandenen Stack-Overflow-Fragen zu dem Thema gefunden, aber ihre akzeptierten Antworten sind tatsächlich widersprüchlich, selbst wenn sie als Duplikate voneinander markiert sind.

Die akzeptierte Antwort auf die erste Frage erwähnt, dass app.config-Dateien tatsächlich während der Kompilierung verwendet werden, was bedeutet, dass sie Auswirkungen haben können. Quellen wie MSDN und MSBuild-Quellcode werden dort als Nachweis zitiert, der während der Kompilierzeit verwendet wird. Leider beherrsche ich MSBuild nicht, um zu verstehen, wie es verwendet wird und ob es wirklich ein gültiges Argument ist.

Kann jemand ein Beispielszenario beschreiben, um zu beweisen, dass eine app.config mit verbindlichen Weiterleitungen für eine Klassenbibliothek etwas bewirken kann?

36
Tom Pažourek

Ich habe mehrere Anwendungen mit einem ähnlichen Setup - Webanwendung, die auf mehrere Bibliotheksprojekte verweist, die jeweils eigene Nuget-Pakete usw. haben. Aufgrund meiner persönlichen Erfahrung werden die Assembly-Bindungen in den Bibliotheksprojekten zur Laufzeit nicht berücksichtigt. 

Bei den Bindungen, die in der Stammanwendung (Web/Konsole) als Web- oder App-Konfiguration angegeben sind, ist nur das von Bedeutung. Alle meine Bibliotheksprojekte werden mit der Einstellung "In Ausgabeverzeichnis kopieren" für die Datei "app.config" als "Nicht kopieren" festgelegt. Auf diese Weise wird mein Ausgabeordner nicht mit der DLL und ihren Konfigurationsdateien überladen. 

Hier ist der Link der sagt, wie die Assembly geladen wird und wo sie gesucht wird und in welcher Reihenfolge. Nein, in dem Artikel wird über einzelne Projekt-Konfigurationsdateien gesprochen. 

Hoffentlich hilft das.

2
Karun

Laut diesem alten Msdn-Artikel :

Eine Anwendungskonfigurationsdatei ist eine XML-Datei, die zur Steuerung der Assembly-Bindung verwendet wird. Es kann eine Anwendung von einer Version einer Side-by-Side-Assembly zu einer anderen Version derselben Assembly umleiten. Dies wird als anwendungsspezifische Konfiguration bezeichnet. Eine Anwendungskonfigurationsdatei gilt nur für ein bestimmtes Anwendungsmanifest und abhängige Assemblys. Isolierte Komponenten, die mit einem eingebetteten Manifest [ISOLATIONAWARE_MANIFEST_RESOURCE_ID] kompiliert wurden, erfordern eine separate Anwendungskonfigurationsdatei. Mit CreateActCtx verwaltete Manifests erfordern eine separate Anwendungskonfigurationsdatei.

Daher verwenden nur DLLs mit dem ISOLATIONAWARE_MANIFEST_RESOURCE_ID-Set tatsächlich eine unabhängige Anwendungskonfiguration, ansonsten wird sie auf die Hauptprozesskonfigurationsdatei verschoben.

Weitere Informationen zu ISOLATIONAWARE finden Sie in diesem anderen MSDN-Artikel , der ausführlicher behandelt wird.

ISOLATIONAWARE_MANIFEST_RESOURCE_ID wird hauptsächlich für DLLs verwendet. Es sollte verwendet werden, wenn die DLL andere private Abhängigkeiten als .__ wünscht. Standard verarbeiten. Wenn zum Beispiel eine DLL von comctl32.dll .__ abhängt. Version 6.0.0.0. Es sollte eine Ressource vom Typ RT_MANIFEST, ID .__ haben. ISOLATIONAWARE_MANIFEST_RESOURCE_ID, abhängig von der Version comctl32.dll 6.0.0.0, so dass selbst wenn die ausführbare Datei des Prozesses comctl32.dll Version 5.1 will, die DLL selbst die richtige Version von .__ verwendet. comctl32.dll.

2
Roy Sanchez

Die Antwort ist vielleicht . Abhängig von der Art des Projekts ist die Bibliotheksdatei. Einige Bibliotheksprojekte werden in Kontexten ausgeführt, in denen die Konfigurationsdatei der Bibliothek beachtet wird (z. B. Azure Web Roles). Dies ist jedoch nicht die Norm.

Siehe meine Antwort hier für weitere Details.

0
gitbox

Nein, nur der app.config der ausführbaren Datei wird wirksam. Wenn Sie beispielsweise über eine Konsolenanwendung verfügen, die einen WCF-Dienst hostet, und in Ihrem WCF-Dienst beispielsweise ConfigurationManager.AppSettings verwenden, werden die AppSettings aus der Host app.config-Datei der Konsole stammen. Wenn Sie eine andere Konsolenanwendung (ConsoleClient) starten, um eine Verbindung zum ConsoleHost herzustellen, wird in den Bereichen, in denen der ConsoleClient als "ausgeführt" bezeichnet werden kann (beispielsweise in seiner Hauptmethode), der app.config des ConsoleClient verwendet, jedoch sobald Sobald der WCF-Dienst verwendet wird, wird der WCF-Dienst die Verwendung von ConsoleHosts app.config delegieren. (Beachten Sie, dass dieser letzte Punkt jedoch für die Details hinter der WCF relevanter ist.) 

Überraschenderweise lieferte msdn diese großartige Quelle: https://social.msdn.Microsoft.com/Forums/vstudio/en-US/e13194df-6308-4cbe-973c-f6a462f43eae/how-can-wcf-library -dll-access-application-settings? referrer = http: //social.msdn.Microsoft.com/Forums/vstudio/en-US/e13194df-6308-4cbe-973c-f6a462f43eae/how-can-wcf-library-dll -access-application-settings? referrer = http: //social.msdn.Microsoft.com/Forums/vstudio/en-US/e13194df-6308-4cbe-973c-f6a462f43eae/how-can-wcf-library-dll-access -application-settings? forum = wcf

Im Allgemeinen gibt es nur eine Konfigurationsdatei. Dies ist die Konfigurationsdatei der ausführbaren Datei (.exe.config, web.config).

Alle Assembly-Weiterleitungen müssen in die Konfigurationsdatei der ausführbaren Datei eingefügt werden. 

Konfigurationsdateien von DLLs müssen mithilfe der ConfigurationManager-Klasse manuell geladen werden. Siehe auch diese Frage Entspricht 'app.config' für eine Bibliothek (DLL)

0
Jehof