Entwickeln und Debuggen mit Nuget-Bibliotheken

Question

Wir haben entschieden, nuget für die Verwaltung von privaten (.NET) Bibliotheken zu verwenden, aber bereits die Versionierung von DLLs wird mühsam.

Lassen Sie uns sagen, dass wir die folgenden Shared Libraries über zwei Projekt:

• Shared_DAL
• Shared_Model
• Shared_BLL (Abhängig von Shared_DAL und Shared_Model)
• Shared_Mvc (Abhängig von Shared_BLL und Shared_Model

Dann haben wir in jedem spezifischen Projekt:

• Project_Model (Abhängig von Shared_Model)
• Project_BLL (Abhängig von Shared_DAL, Shared_Model und Project_Model)
• Project_Mvc (Abhängig von Shared_Model, Shared_BLL, Project_Model und Project_BLL)

Das Problem Wir haben gerade festgestellt, dass es sehr schwierig ist, Änderungen an Shared_BLL in einem bestimmten Projekt zu testen. Derzeit haben wir zu:

• Shared_BLL Bauen als nuget Paket
• das nuget Paket
• Run-Update-Package Shared_BLL in der Lösung zum privaten Repository bereitstellen enthält Project_Mvc und Project_BLL

Das ist extrem schwierig und ein großer Overhead.

Wir haben einen anderen Ansatz versucht, bei dem man die DLL-Referenzen vorübergehend entfernt und sie durch direkte Verweise auf die modifizierten DLLs ersetzt. Aber dann müssen Sie alle Änderungen am Projekt rückgängig machen, die nicht besonders gut sind.

Fehle ich hier etwas? Wenn Sie NuGet in Ihrem Entwicklungszyklus verwenden, wie gehen Sie mit DLLs um?

Update: Für Menschen, die das gleiche Problem konfrontiert sind, wir sind umgezogen von nuget weg, bis diese aussortiert wird, und verlassen sich auf DLLs in einem bestimmten Ordner setzen, und verwenden Sie absolute Pfade im HintPath in jedem Projekt Datei. Build-Ereignisse aktualisieren die DLLs im definierten Verzeichnis, und sowohl Shared als auch Project können debuggt werden.

Answer 1

Ich sehe, dass Sie wieder auf einfache DLL anstelle von Nugget-Paket verweisen, aber ich entschied mich zu antworten. Vielleicht wird sich jemand anderes für meine Meinung zu diesem Thema interessieren.

Schließlich habe ich große Forschung darüber, und ich fand einige Fakten, die verwendet werden können, um Probleme mit dem Wechsel zwischen Remote-Nugget-Referenz und lokalen Nugget-Referenz zu umgehen.

Es ist möglich, nuget update aufzurufen, um die neueste Version des angeforderten Pakets zu referenzieren. So ... zum Beispiel haben Sie zwei Nuget-Repositories (remote und lokal). Das lokale Repository ist ein normaler Ordner.

1. You build Project_Mvc from plain sources and nuget automatic restore downloads
 Shared_BLL-1.0.0 from remote repository where you have your "production builds" 
2. You decided to build Shared_BLL locally. As you do it in your IDE it generates 
    Shared_BLL.9.99.999.0 package. 
3. You call update and rebuild Project_Mvc and voila! Shared_BLL.9.99.999.0 is now 
    referenced here. 

Sie schrieb, dass dieser große Aufwand ist ... Es kann durch das Hinzufügen zusätzlicher Projekte VS-Lösung automatisch erfolgen. Zum Beispiel _UpdatePackages-Projekt (Leere C# -Projektvorlage), das immer über der Projektliste der Lösung steht. Zusätzlich kann dies auch rückwärts durchgeführt werden. Wenn Sie Shared_BLL.9.99.999.0 aus dem lokalen Feed löschen und die Aktualisierung aktualisieren, wird die Referenz durch die von Punkt 1 ersetzt.

Eine andere Möglichkeit, dieses Problem zu beheben, ist die Verwendung von ripple. Ich könnte dies in meinem Projekt wegen einiger Einschränkungen nicht verwenden, aber es kann in Ihrer Situation in Ordnung sein.