Frage

Ich bin verantwortlich für die Entwicklung und Aufrechterhaltung einer Reihe von gemeinsamen Rahmenbaugruppen, mit denen unsere Produktanwendungen erstellt werden. Diese Versammlungen sind relativ neu und in einem Zustand des Flusses, wenn neue Funktionen implementiert sind usw. Infolgedessen ist es nicht ungewöhnlich, dass sie wieder aufgebaut und etwas häufig verteilt werden. Ich würde erwarten, dass dies abnimmt, wenn die Baugruppen stabalisiert werden, aber es ist das, was es heute ist.

Derzeit werden die Baugruppen in einen gemeinsamen Ordner gegeben, in dem die Entwicklungsprojekte auf dieselben Baugruppen hinweisen können. Das Anwenden von Updates ist so einfach wie das Austausch der Dateien und die Entwicklungsprojekte, die die Änderungen beim nächsten Laden und Erstellen automatisch aufnehmen.

Das Problem, das ich habe, ist, dass wir möglicherweise mehrere "Ebenen" von Assemblys auf dem Framework basieren. Zum Beispiel haben wir eine Kernbibliothek, die von allen Anwendungen freigegeben wird, und eine Serverbibliothek, die sich auf den Kern verweist und von allen Serveranwendungen gemeinsam genutzt wird. Alle Abhängigkeiten müssen auch jedes Mal wieder aufgebaut werden, wenn die Framework -Baugruppen aktualisiert werden, was dies zu einer sehr großen Aufgabe macht. Ich glaube nicht, dass ich den GAC verwenden kann, da dies erfordern würde, dass alle Entwickler ihre Systeme jedes Mal aktualisieren, wenn eine neue Version veröffentlicht wird.

Ich habe Publisher -Richtlinien untersucht, habe aber einige Zweifel daran, dass dies mein Problem aus einigen Gründen lösen wird:

  • Zum einen möchte ich die Datei nicht jedes Mal neu erstellen, wenn ich meine Framework -Assemblys wieder aufbauen kann? Kann ich diesen Prozess automatisieren?

  • Mir ist nicht klar, ob die Baugruppen in den GAC gehen. Wie gesagt, ich möchte meine Entwickler nicht zwingen, jedes Mal neu zu installieren, zu aktualisieren usw., wenn wir eine neue Version der Versammlungen veröffentlichen.

  • Ich habe keine Kontrolle über das Netzwerk -Setup und die Konfiguration. Daher ist es erforderlich, das gesamte "Trust" -Problem zu vermeiden, indem die Dateien in einer Netzwerkfreigabe platziert werden. Außerdem arbeiten viele unserer Entwickler manchmal verbunden, und wir möchten, dass die Dateien ihnen beim Trennen verfügbar sind.

Ziel wäre es, diese Versammlungen für unsere Anwendungsentwickler, die sie konsumieren, transparent zu machen. Wir werden diese Baugruppen zweifellos in der GAC auf der Zielmaschine installieren, wenn die Anwendung installiert ist, aber wir möchten dies nicht für Entwicklungszwecke tun. Es ist auch nicht vernünftig, die Projekte in die Lösung der einzelnen Anwendungen aufzunehmen, da sie von verschiedenen Teams entwickelt werden.

Ich kann mir nicht vorstellen, dass ich allein in diesen Anforderungen bin und hoffe, dass jemand seine Erfahrungen und Weisheit teilen kann, um mich zu einer Lösung zu führen. Vielen Dank!

War es hilfreich?

Lösung 2

Nuget hat dieses Problem gelöst. Durch die Verteilung der gemeinsam genutzten Assemblys, Frameworks usw. als Nuget -Pakete aus einem privaten Repository in unserem Netzwerk können wir problemlos Aktualisierungen veröffentlichen und sie gegebenenfalls auf den Client -Code anwenden lassen.

Andere Tipps

Sie müssen die Baugruppen nicht unbedingt in den GAC installieren - nichts in Ihrem Setup erfordert dies.

Das Hauptproblem ist hier, dass eine Versammlung alle Abhängigkeiten zum Wiederaufbau zwingt und dass alle diese an einem gemeinsamen Ort platziert werden.

Die einfachste Option hier wäre wahrscheinlich, einen Build -Server zu haben, der alles wieder aufbaut, wenn eine der gemeinsam genutzten Baugruppen aktualisiert wird. Dies hat auch den Vorteil, dass potenziell andere "Skripte" im Build ausgeführt werden kann, z. B. Code -Metriken, statische Codeanalyse usw., wenn ein Build eingecheckt wird.

Sie können dann nur den Build -Server an einen gemeinsam genutzten Ort kopieren lassen. Wenn die Projekte aus dem gemeinsamen Standort verweisen und ausdrücklich sagen, dass sie sich nicht auf eine bestimmte Version beschränken, sollte alles nur einwandfrei funktionieren.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top