Binding Redirect wird zu jedem app.config hinzugefügt

Question

Ich habe 20 Projekte in einer Lösungsdatei. Eines der Projekte ist ein Standard-Bibliotheksprojekt, auf das sich alle Projekte beziehen.

Vor etwa einem Jahr haben wir ein neues nuget-Paket hinzugefügt, wir nennen es Package A Version 5.0.0.0. Es hatte eine Reihe von Dateien, die es beim Kompilieren übertragen würde, aber wir haben uns schließlich damit beschäftigt. Wir haben das Paket zu unserem Standard-Bibliotheksprojekt hinzugefügt (das eine die anderen 19 Referenzen).

Ich bin neu bei Nuget (also vielleicht habe ich etwas falsch gemacht), also habe ich ein neues Paket gemacht, um als Helfer für Package A zu dienen. Ich hatte alles eingerichtet, so dass der Helfer eine Abhängigkeit von Package A Version 3.0.0.0 zu 5.0.0.0 hat (also funktioniert es für andere, die eine niedrigere Version als wir haben). Lassen Sie uns dieses neue Paket anrufen Package A helper

Ich installiere Package A helper und alles funktioniert wie es sollte. Ich gehe einen Pull-Anforderung und jede einzelne app.config in unsere Lösung jetzt

<runtime> 
     <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"> 
       <dependentAssembly> 
         <assemblyIdentity name="Package.A" publicKeyToken="8FC3CCAD86" culture="neutral"/> 
         <bindingRedirect oldVersion="0.0.0.0-5.0.0.0" newVersion="5.0.0.0"/> 
       </dependentAssembly> 
     </assemblyBinding> 
</runtime> 

zu tun hat, wird es in Ordnung zusammenstellen, ohne sie, aber Visual Studio beschwert sich und gibt eine Warnung aus. Was gibt? Mein Manager lässt mich meinen Code jetzt nicht zusammenführen, weil er zu viel Rauschen in app.config hinzufügt und zu sehr von Paket A abhängt.

Warum musste das Hinzufügen eines nugget-Pakets, das von Package A abhing, dann dieses neue bindingRedirect haben Wann wurde die Hauptabhängigkeit bereits erfüllt, bevor wir Package A Helper installiert haben?

Und warum es 0.0.0.0-5.0.0.0 sagt, wenn ich 3.0.0.0-5.0.0.0 im nuget Paket und package.config

-Update angegeben:

Wenn ich Package A helper mit Referenzen bauen Nach Package A Version 5.0.0.0 werden dann alle bindingRedirects nicht automatisch in jeder app.config aufgefüllt, stattdessen werden Warnungen generiert. Ich hatte es ursprünglich mit 3.0.0.0 gebaut, weil ich dachte, dass es am besten ist, es mit der niedrigsten Abhängigkeit zu bauen. Das Problem besteht weiterhin, da Visual Studio weiterhin warnt und vorschlägt, dass BindingRedirects erstellt wird.

No way to resolve conflict between "Package A, Version=5.0.0.0, Culture=neutral, PublicKeyToken=83hfhsd33" and "Package A, Version=3.0.0.0, Culture=neutral, PublicKeyToken=83hfhsd33". Choosing "Package A, Version=5.0.0.0, Culture=neutral, PublicKeyToken=83hfhsd33" arbitrarily. 
Consider app.config remapping of assembly "Package A, Culture=neutral, PublicKeyToken=83hfhsd33" from Version "3.0.0.0" [] to Version "5.0.0.0" [path to Package A dll] to solve conflict and get rid of warning. 

Ist die Lösung nur meine nuget Paketabhängigkeit von 3.0.0.0 bis 5.0.0.0 zu ändern und nur 5.0.0.0 erlauben und packages.config meine allowedVersions="[3,6)" in mir loswerden? Ich möchte die Hilfsbereitschaft und Rückwärtskompatibilität meines Pakets nuget nicht reduzieren, aber gleichzeitig möchte ich keine Warnungen oder verbindlichenRedirects für meine Hauptlösung benötigen.

Update 2: Also Einstellung Copy Local in den Referenzeigenschaften zu False tatsächlich löste meine Probleme, aber ich verstehe nicht warum.

Answer 1

ich ursprünglich mit 3.0.0.0 gebaut hatte, weil ich dachte, es am besten war ...

Das ist, wo das Problem begann. Ihre Lösung hängt jetzt von zwei verschiedenen Versionen von A.dll, eine wird die andere überschreiben. Welche Version von A.dll in bin \ Debug kopiert wird, ist zufällig. Welches Projekt wurde zuletzt gebaut?

Dies kann nicht zu einem guten Ende kommen, die Lösung ist zum Scheitern verurteilt zu führen. Wenn der Code in A-helper.dll ist, wird es fehlschlagen, wenn Version 5.0.0.0 kopiert wird.Oder es wird der Code in jedem anderen Projekt verwendet A.dll, es wird fehlschlagen, wenn Version 3.0.0.0 kopiert wird. Endergebnis ist, dass die Lösung immer fehlschlägt.

Sie sehen also, dass das Build-System etwas dagegen tut. Es bemerkt die Diskrepanz und wählt eine der Versionen, um zu gewinnen. Es wählt 5.0.0.0, das war die richtige Wahl. Und es auch ändert app.config und fügt die bindingRedirect so Code, der nach der 3.0.0.0 Version fragt, wird tatsächlich 5.0.0.0 erhalten. Das könnte funktionieren, wenn Sie Version 5 genug kompatibel mit Version 3 gemacht haben. Oder nicht, zwei Schritte in der Hauptversionsnummer buchstabiert normalerweise Schwierigkeiten. Sie werden es herausfinden, wenn Sie testen.

So Lokale Kopie Einstellung tatsächlich in der Referenz Eigenschaften auf False meine Probleme gelöst

Das ist nicht ein Problem gelöst hat, können Sie nur das Build-System von der Annahme verhindert, dass es dieses Problem für Sie lösen soll. Da die DLL nicht mehr kopiert werden musste, wird davon ausgegangen, dass Sie die Assemblys im GAC installieren, sodass beide Versionen nebeneinander existieren können. Vielleicht hast du es getan, es ist nicht üblich und im Allgemeinen sehr unklug, dies auf einer Dev-Maschine zu tun. Sehr unwahrscheinlich, dass Ihr Chef und Ihre Teammitglieder diese Lösung angesichts des zusätzlichen Installationsschritts mögen.

---

So gibt es zwei grundlegende Dinge, die Sie tun können:

• das Buildsystem sortieren diese Ausgelassener. Wie es tat, löste es das Problem richtig und Ihre Lösung wird funktionieren. Wenn Version 5 mit Version 3 kompatibel genug ist, wird der Code in A-helper.dll sogar korrekt ausgeführt. Wenn der Chef es nicht mag, dann müssen Sie das natürlich scratchen und tun:

• Ändern Sie die Referenz im A-Helfer-Projekt in A-Version 5.0.0.0. Jetzt gibt es keine Inkompatibilität mehr, die einzige A.dll ist gut für den gesamten Code. Angesichts Ihrer Anforderung ist dies die einzige Lösung, die Ihrem Chef gefallen wird.