2016-06-20 13 views
1

Ich habe ein Projekt A mit Abhängigkeit B über Nuget. Abhängigkeit B kommt von einem anderen Team und liegt außerhalb meiner direkten Kontrolle.Überschreiben Sie die Abhängigkeit von Nuget-Paket im Nachbau

Das nuget-Paket für B enthält Abhängigkeiten für B einschließlich Common.Logging v1.2. Dies wird an Ort und Stelle über die Zieltargetdatei von B (etwa <Copy SourceFiles='@(PackageBManagedFiles)' DestinationFolder="$(TargetDir)\"/>)

kopiert. Ich benötige außerdem einen Verweis auf Common.Logging in Projekt A, aber mit späterer Version 3.0. Ich habe dies mit nuget hinzugefügt und die Referenz in Visual Studio sieht ok.

Als ich brauche zwei Versionen von Common.Logging, ich habe eine assemblyBinding in die app.config-Datei hinzugefügt, so etwas wie:

<dependentAssembly> 
    <assemblyIdentity name="Common.Logging" publicKeyToken="xxx" culture="neutral" /> 
    <bindingRedirect oldVersion="0.0.0.0-3.0.0.0" newVersion="3.0.0.0" /> 
    </dependentAssembly> 

So ideal würde Ich mag die Version 3.0 von Common.Logging zu sein in meinem bin-Verzeichnis.

Version 1.2 endet jedoch in meinem bin-Verzeichnis - und daher funktioniert die Anwendung nicht.

Ich habe versucht, zurück zu Version 3.0 mit einem Post-Build-Ereignis zu überschreiben. Das Echo des Inhalts des bin-Verzeichnisses auf eine Datei während des Post-Build-Ereignisses (etwa dir $(TargetDir) > dir.txt) zeigt, dass die Dateikopie funktioniert hat, aber zu dem Zeitpunkt, an dem der Build abgeschlossen wurde, ist die alte Version der Datei wieder vorhanden. Diese

legt nahe, dass die Reihenfolge der Build ist wie folgt:

  1. Abhängigkeiten in Ort kopiert

  2. Post bauen Ereignisse laufen

  3. nuget Ziele Datei für Paket B laufen

Das deutet darauf hin, dass ich könnte cr Erhalte mein eigenes nuget-Paket mit Common.Logging 3.0, das eine Zieldatei enthält, um die neue 3.0-DLL über die alte 1.2-DLL-Datei zu kopieren - aber nur, wenn ich die Reihenfolge garantieren könnte, in der die nugget-Pakete/targets-Dateien ausgeführt wurden.

Irgendwelche Ideen, wie ich Common.Logging 3.0 nach einem Build in mein bin-Verzeichnis bekommen kann?

Antwort

0

Ich "fixierte" dies, indem ich ein neues nuget-Paket erstellte, das Common.Logging 3.0 enthielt, über die Zieldatei in die richtige Position kopiert wurde und das nuget-Paket zzzCommonLoggingToBeInstalledLast nannte.

Beachten Sie, dass Nuget alphabetisch über packages.config funktioniert, dies hat den Job zuverlässig auf dem lokalen/Build-Server ausgeführt.

Ein bisschen ein Hack, aber fügte hinzu, wie es eine nützliche schnelle Lösung am Ende war, und ich könnte ein paar Kommentare hinzufügen, um den Hack innerhalb der Nuget-Paket für andere Entwickler zu erklären, wofür das war. Wenn jemand eine bessere Lösung hat, lösche ich diese Antwort gerne.

Verwandte Themen