Wie teilen Sie sich externe Abhängigkeiten, die zwischen den Visual Studio-Lösungen?

Ich habe ein Java-hintergrund, ich bin also verwendet, um mit Maven Griff alle problem rund um das herunterladen und halten Abhängigkeiten auf dem neuesten Stand. Aber in der .NET Umgebung habe ich noch nicht gefunden, ein guter Weg, um zu verwalten Sie sämtliche externen Abhängigkeiten.

Das größte problem hier ist, dass ich Masse produzieren Lösungen, und Sie alle neigen dazu hängen auf der selben Drittanbieter-dll ist. Aber ich will nicht behaupten, separate Kopien der einzelnen Komponenten unter der jeweiligen Lösung. Also brauche ich eine Möglichkeit, die Verknüpfung all der verschiedenen Lösungen auf den gleichen Satz von dll-Dateien.

Erkannte ich, dass eine Lösung sein könnte, enthalten die externen Bibliotheken in einer "Bibliothek-Projekt", die enthalten ist in allen Lösungen und lassen Sie die anderen Projekte Referenzen Sie über Sie. (Oder stellen Sie sicher, dass verweisen auf die externe dll ' s aus dem gleichen Ort bei allen Projekten.)

Aber gibt es bessere Möglichkeiten, dies zu tun?
(Vorzugsweise über irgendeine Art von plug-in für Visual Studio.)

Habe ich mir angeschaut, die Visual Studio Abhängigkeiten-Manager und es scheint wie eine perfekte übereinstimmung, aber habe jemand versucht, es für real? Ich habe auch gesehen, das .NET-ports von Maven, aber leider war ich nicht zu beeindruckt von der status dieser. (Aber bitte, gehen Sie vor und empfehlen Sie jemand, wenn Sie denken, ich sollte Ihnen noch einmal zu versuchen.)

Also, was wäre der intelligenteste Weg, um dieses problem anzugehen?

Update:

Ich erkannte, dass ich brauchte, um zu erklären, was ich meinte mit Verlinkung auf die gleichen dll ' s.

Eines der Dinge, die ich versuche zu erreichen ist, um zu vermeiden, daß die verschiedenen Lösungen auf verschiedenen Versionen der einzelnen Komponenten. Wenn ich ein update einer Komponente auf eine neue version, es sollte aktualisiert werden, für alle Lösungen, die bei der nächsten build. Das würde mich zwingen stellen Sie sicher, dass alle Lösungen up to date mit den neuesten Komponenten.

Update 2:
Beachten Sie, dass dies ist eine alte Frage, die gestellt wird, bevor tools wie NuGet oder OpenWrap existierte. Wenn jemand bereit ist, eine mehr up-to-date, bitte gehen Sie weiter, und ich werde ändern Sie die akzeptierte Antwort.

  • Welche Art von source-control-tool verwenden Sie?
  • SVN aber dies ist keine Voraussetzung für eine gute Lösung. Ich kann einfach Umschalten Umgebung.
InformationsquelleAutor Ola Herrdahl | 2009-08-01
  1. 2

    1. Suchen Sie einen Ort zum speichern der Baugruppen. Zum Beispiel Lagere ich die .Net-core-Baugruppen wie folgt:

      • <branch>\NetFX\2.0527\*
      • <branch>\NetFX\3.0\*
      • <branch>\NetFX\3.5\*
      • <branch>\NetFX\Silverlight 2\*
      • <branch>\NetFX\Silverlight 3\*

    2. Verwenden Sie die ReferencePath-Eigenschaft in MSBuild (oder AdditionalReferencePath im Team-Build), um zu zeigen Sie Ihre Projekte in die entsprechenden Pfade. Für Einfachheit, einfache Wartung und, ich habe 1 *.Ziele-Datei, die kennt jedes solche Verzeichnis; alle meine Projekte Importieren, die Datei.

    3. Stellen Sie sicher, dass Ihre version control Strategie (branching, merging, lokale<->server-mappings) hält die relativen Pfade zwischen Ihre Projekte & Ihre Referenz Pfade konstant.

    BEARBEITEN

    In Reaktion auf das update in der Frage, lassen Sie mich hinzufügen: ein weiterer Schritt:

    4) Stellen Sie sicher, jede assembly-Verweis in jede Projekt-Datei verwendet die vollen .Net strong name und nichts anderes.

    Schlecht:

    <Reference Include="Microsoft.SqlServer.Smo">
  <SpecificVersion`>False</SpecificVersion>
  <HintPath>..\..\..\..\..\..\..\Program Files (x86)\Microsoft SQL Server\100\Shared\Microsoft.SqlServer.Smo.dll</HintPath>
</Reference>

    Gut:

    <Reference Include="Microsoft.SqlServer.Smo, Version=10.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91, processorArchitecture=MSIL" />

    Vorteile der letzteren format:

    • Mit einem HintPath in einer kollaborativen Entwicklungsumgebung wird unvermeidlich zu Situationen führen, wo "es funktioniert für mich", andere aber nicht. Besonders Ihre server zu bauen. Weglassen, es zwingt Sie, um Ihre referenzpfade korrigieren oder es wird nicht kompiliert.
    • Mit einem schwachen Namen lädt der Möglichkeit der "DLL-Hölle." Wenn Sie starke Namen, dann ist es sicher mehrere Versionen der gleichen assembly in Ihre Referenz-Pfaden, da der linker nur laden diejenigen, die Spiel jedes Kriterium. Darüber hinaus, wenn Sie sich entscheiden, zu aktualisieren, einige Versammlungen statt (anstatt Kopien), dann wirst du benachrichtigt werden aktuelle änderungen zur compile-Zeit statt , wenn die bugs kommen in.
    • Ja, natürlich, MSBuild. Ich denke, es war nur eine Frage der Zeit, bevor ich hatte, um zu erfahren, wie es zu benutzen... 😉 Das klingt wie eine gute Allgemeine Lösung, aber ich bin noch offen für andere Vorschläge.
    • Siehe mein update zu update.
    • Danke, das hilft, obwohl meine Probleme sind, dass ich dazu gezwungen werde, schwachen Namen für einige Abhängigkeiten. E. g. mef.codeplex.com/Thread/View.aspx?ThreadId=57524 (ich bin nicht ganz bereit für die .NET 4.0 beta noch nicht.) So das ist der Kern meines Problems, aber nun ist es wohl gelöst. Ich muss nur ein Skript schreiben, das findet und entfernt alle lokalen Assemblys in einer Lösung, machen sicher, es kann nur reference assemblies wies darauf hin, durch die ReferencePath Eigenschaft.
    • Ja, wenn das Projekt ist groß genug, um mehrere Entwickler und mehrere externe Abhängigkeiten, in der Lage, es zu bauen, mit MSBuild oder MS-Team zu Bauen, ist nahezu unerlässlich. Eine Seite ein Hinweis über die Verwendung starker Namen: ich habe Menschen gesehen, die in Schwierigkeiten geraten, weil Sie mit schwach-namens <Verweis>s zu anderen (sub-)Projekte anstelle von <ProjectReference>. Wenn Sie eine Abhängigkeit von einem anderen Projekt (z.B. DLL) entwickelt, die von Ihrem team, es ist besser den code in der gleichen source tree (oder verwenden Sie svn:externals) und Nutzung ein <ProjectReference>, für den gleichen Gründen, Richard oben aufgezählt.
    • Ich Stimme Ihrer Aussage über Projekt-Referenzen und svn:externals statt der DLL verweist. Ist dies ein "best practice" für .NET, und wenn ja, ist es irgendwo veröffentlicht? Wir sind mit Jenkins und jetzt versuchen übergeben Artefakte von job zu downstream-job.
    InformationsquelleAutor Richard Berg
  2. 1

    Zugabe zu dem, was alle anderen sagt, im Grunde kommt es auf zwei Dinge:

    1. Machen Sie sicher, dass alle Entwickler die gleichen Versionen der externen Bibliotheken
    2. Machen Sie sicher, dass alle Entwickler haben die externen Bibliotheken am selben Ort befinden (zumindest, relativ zu dem Quell-code)

    Als Richard Berg Punkte aus, die Sie verwenden können, ReferencePath und/oder AdditionalReferencePath zu lösen #2. Wenn Sie mit msbuild in Ihren build-Prozess (in unserem Fall verwenden wir CruiseControl anstelle von MS-Team zu Bauen), Sie kann auch passieren ReferencePath, um es auf der Kommandozeile. Zu lösen #1, die ich gefunden habe,svn:externals, um nützlich zu sein (wenn Sie mit SVN).

    Meine Erfahrung mit Maven ist, dass es die Weise ist, die overkill für die meisten Zwecke.

    • Ja, das ist eigentlich fast das, was ich gerade mache. Ich bin mit svn:externals wird, um andere Dinge gemeinsam für alle Lösungen. Dies ist wahrscheinlich eine gute Lösung in den meisten Fällen und wäre meine fallback für die Abhängigkeiten zu. Aber dennoch möchte ich eine schnellere/einfachere Möglichkeit zum verwalten der Abhängigkeiten, vorzugsweise ohne Sie zu speichern im SVN überhaupt. Ich habe gerade versucht das Visual Studio Abhängigkeiten-Manager und es gibt mir die Geschwindigkeit, die ich bin auf der Suche nach, während die Verwaltung von Abhängigkeiten (drag-und-drop aus einem repository sowie eine ein-Klick-update auf die neueste).
    InformationsquelleAutor Daniel Pryden
  3. 0

    Normalerweise habe ich eine eigene Ordnerstruktur auf der source-control für externer oder Interner Abhängigkeiten, und diese filders haben die Baugruppen nach der build-oder Versionsnummer, zum Beispiel

    public\External\libraries\Nunit\2.6\

    oder

    Public\Internal\libraries\Logger\5.4.312\

    innen die Lösungen alle Projekte, die mit beliebigen Abhängigkeiten fügt nur einen Verweis auf diesen Versammlungen in der öffentlichkeit interner oder externer Ordner.

    InformationsquelleAutor bashmohandes
Schreibe einen Kommentar