it-swarm.com.de

Sollte eine Lösung mit Projekten, die als Nuget verfügbar gemacht wurden, auf diese als Paket verweisen?

Mein Projekt ist für das Beispiel verkleinert und so aufgebaut:

  • lösung X
    • projekt A.
    • projekt B.

Projekt A wird als Nuget Pakete extern verfügbar gemacht, Projekt B benötigt die Funktionalität von - Projekt A.
Diese Projekte sind aufgrund der korrekten Namespace-Zuordnung und der logischen Isolation vorhanden, nicht aufgrund der Verwendung außerhalb von Lösung X: Wenn Projekt A aktualisiert, müssen keine externen Lösungen aktualisiert werden .

Ist es in Ordnung, direkt auf Projekt A von Projekt B zu verweisen, ohne das Paket nuget zu verwenden? Vermisse ich einige Best Practices? Weil ich keinen Grund sehe, die Komplexität der DLL Release-Verwaltung mit Nuget zu erhöhen. Projekte nur intern die gleiche Lösung zu verwenden.

5
Giulio Caccin

Wenn ich das richtig verstanden habe, gibt es kein Projekt mehr, das A als Nuget-Paket verbraucht, sobald Sie die Nuget-Referenz von B nach A durch eine Projektreferenz ersetzen, oder?

Wenn es also keinen Verbraucher mehr gibt, ist es ziemlich offensichtlich, dass das Nuget-Paket überflüssig ist.

Lassen Sie mich hier ein weiteres Szenario skizzieren: Was ist, wenn es in Zukunft ein weiteres externes Projekt C geben wird, das A von einem Nuget-Paket konsumieren möchte? Sollte B dann geändert werden, um A auch als Nuget-Paket zu konsumieren? Oder ist es in Ordnung, B mit einer einfacheren Projektreferenz direkt auf A verweisen zu lassen?

Meiner Erfahrung nach rechtfertigt die bloße Existenz von C keine Änderung des Referenzmechanismus, solange B immer die neueste Version von A konsumieren möchte und A & B Teil desselben Produkts sind. Es kann durchaus sinnvoll sein, A sich durch einen Mechanismus "intern" und durch einen anderen extern aussetzen zu lassen.

Wenn es sich bei B jedoch hauptsächlich um ein Testprojekt handelt, das geschrieben wurde, um sicherzustellen, dass das extern exponierte Projekt A wie beabsichtigt funktioniert, ist es wahrscheinlich eine gute Idee, B genau denselben Referenzmechanismus wie ein externer Verbraucher C verwenden zu lassen. Tests für Komponenten sollten simuliert werden die Aspekte eines echten Verbrauchers so ähnlich wie möglich.

Wenn C auch auf B verweist und Sie damit beginnen, A, B und C als ein Produkt bereitzustellen, ist es wahrscheinlich eine gute Idee, die verschiedenen Referenzmechanismen nicht zu mischen. Andernfalls erhalten Sie C, das direkt auf Version 1.0 von A und Version 1.1 indirekt über B verweist, was in einer Art DLL Hölle) endet. In diesem Fall kann man jedoch in Betracht ziehen A, B und C Teil derselben Lösung zu haben und nur Projektreferenzen zu verwenden.

5
Doc Brown

Wenn Projekt A als Nuget-Paket veröffentlicht wird, wird es im Allgemeinen als Nuget-Paket verwendet.

Jetzt wissen wir alle, dass es einfacher ist, eine direkte Referenz zu erstellen, wenn Sie B und A zusammen bearbeiten. Wenn Ihre Build-Kette die Lösung erstellt und versioniert, ist es außerdem schwierig, die Nuget-Referenz korrekt zu ermitteln.

Wenn Sie jedoch B veröffentlichen, möchten Sie, dass B eine Nuget-Abhängigkeit von A hat. Keine direkte Referenz.

Idealerweise entwickeln und veröffentlichen Sie A und B getrennt, um sicherzustellen, dass Ihre Tests das Endprodukt widerspiegeln.

Ich denke, es ist gängige Praxis, dies zu überspringen, und die neue .net-Core-Build-Kette macht jedes Projekt gerne zu einem Nuget. Welches ist nicht immer optimal.

0
Ewan