2009-06-02 5 views
1

Ich möchte ein Werkzeug oder eine Technik, um die Frage zu beantworten "Welche Version der Datei X wurde verwendet, um Assembly abc.dll zu erstellen?" Ich bin vor kurzem zu einer .NET-Entwicklergruppe gewechselt, und es scheint, als käme diese Frage immer wieder auf, in der einen oder anderen Form, und wir haben sie nicht im Griff. Jemand sagt etwas wie "Hey, ist dein letzter Code auf dem Testserver?" und die Antwort ist zwangsläufig etwas wie "Ich weiß es nicht".Verfolgen der Versionskontrolle auf Dateiebene in Builds mit Visual Studio und .NET?

Zurück in den alten Tagen der Unix-Entwicklung (Ich bin da mit mir selbst), hatte die SCCS-Quellcodeverwaltung special keywords wie% I% (Version) und% M% (Modulname), die Sie in Ihrem platzieren könnten Datei, die bei jedem Auschecken der Datei durch die entsprechende SCCS-Versionsinformation ersetzt wird. Sie könnten also einfach einen konstanten String zu "% I%% M%" in Ihrer Quelldatei zuweisen, kompilieren und dann die Unix "strings" command auf Ihrer resultierenden Bibliothek ausführen, um festzustellen, welche Versionen der Dateien zum Erstellen dieser Datei verwendet wurden .

habe ich einen schnellen Test zum Roll-my-own in einer C# Klassendatei wie folgt aus:

public const String VERSION_STRING = "*VERSION* = MyClass 1.0"; 

diese Befehlszeilen auf meinem DLL-Verzeichnis Dann lief:

>for %f in (*.dll) do find "VERSION" %f 

Aber die Ergebnisse waren:

---------- MYASSEMBLY.DLL 
VERSION_STRING 

die nicht ganz, was ich war nach (es mir den Namen der konstante gab, aber keiner der Version info Ich hatte versucht, manuell in die Klasse einzubetten).

Für was es wert ist, verwenden wir derzeit Clearcase für unsere Versionskontrolle (derzeit der Unternehmensstandard). In Clearcase gibt es einige Tools, die uns hier helfen können (wie clearaudit), aber das würde einige Anstrengungen zur Verfeinerung und Umrüstung unseres Build-Prozesses erfordern. Ich sollte auch erwähnen, dass wir erwägen, einen Wechsel zu Subversion zu steuern. Also denke ich, dass Lösungen, die mit .NET in verschiedenen Versionskontrollsystemen oder Build-Umgebungen (MSBuild, NAnt, CruiseControl) funktionieren, ein faires Spiel sind.

Gibt es noch andere, besonders .NET-zentrierte Lösungen, um zu verfolgen, welche Version welcher Datei in welche Baugruppe importiert wurde?

Antwort

1

Wir haben schnell die Idee aufgegeben, spezielle Schlüsselwörter zu verwenden, da integrierte Metadaten (wie Versionsnummer) in Daten (die im VCS gespeicherten Dateien) im Allgemeinen keine sehr gute Idee ist (siehe die Debatte in dieser SO Frage: "Embedded Version Numbers - Good or Evil?")

Unser Ansatz ist es, eine "Release Note" mit dieser Art von Informationen zu erstellen. Diese einfache Textdatei wird dann zusammen mit der Build-DLL gespeichert.

+0

Ja, mir ist klar, dass das Einbetten von Versionsinformationen mit Clearcase keine gute Option ist. Es ist schade, dass es nicht mehr wie SCCS oder RCS funktioniert, wo die Versionsinformationen bei Bedarf ersetzt werden können, aber nicht in der Datei gespeichert werden. Aber nachdem ich diesen Link gelesen habe, kann ich sehen, wo dieser Ansatz auch ein paar Probleme haben kann. Ich denke, dass hier der Ansatz von Clearcase, einen separaten "Konfigurationsdatensatz" für abgeleitete Objekte zu erstellen, sehr hilfreich ist. (Sie könnten sogar die Versionsnotiz aus dem Konfigurationsdatensatz erstellen, wenn Sie so geneigt waren). –

+0

@ Ogre: In der Tat, aber in der Praxis haben wir nie wirklich DO verwendet. Eine allgemeinere Liste von Versionen, geschrieben nach dem Build, war genug für uns. – VonC

+0

Von den Lösungen und Antworten, die ich bisher vorgestellt habe, gefällt mir diese Version am besten. Ob Sie Nant oder Msbuild verwenden, sollte es nicht zu schwierig sein, diese Art von Lösung zu automatisieren. –

0

Für meine "Community" Arbeit verwende ich ein einfaches Schema; Ich verwende die SVN-Revisionsnummer als Build-Version in den [AssemblyVersion]/[AssemblyFileVersion] Attributen gegen die Baugruppe. Es ist ziemlich einfach, diese sowohl zur Laufzeit als auch über den Explorer abzufragen, und das Skript, um sie zu aktualisieren, ist auch ziemlich einfach - die ersten paar Aufgaben in here.

1

Ich habe positive Erfahrung mit SubVersion und CC.NET Continuous Integration Server.

Sie würden ein NAnt-Ziel einrichten, das am spätesten greift (es könnte das Repository hier sperren), dann baut es. Nachdem der Build fertig ist, erstellt er ein Versions-Tag in SVN.

Die Version einer Datei kann während der Erstellung leicht von der Version eines Tags abgeleitet werden.

+0

So bietet Subversion eine Möglichkeit, die Versionen zu konsolidieren, mit denen alle Quelldateien markiert sind (a.cs, ​​b.cs, c.cs), und irgendwie alle diese Informationen an die resultierende DLL-Datei anzuhängen? Clearcase bietet diese Fähigkeit an (obwohl wir es bei diesem Projekt noch nicht ausnutzen), also bevor wir auf ein anderes Versionskontrollsystem pilotieren oder wechseln, möchte ich sehen, was wir gewinnen oder verlieren. –

+0

Das Repository ist mit einer Revisionsnummer als Ganzes gekennzeichnet. Die Dateirevisionsnummer wird bei jedem Einchecken zugewiesen. Diese Zahlen stammen aus demselben Pool. Wenn also die Dateiversionen 1,2,5,8,9 sind und die Build-Tag-Version 7 ist, wurde die Datei aus Rev. 5 verwendet. – GregC

+0

Richtig, ich habe ein wenig mehr über Subversion und andere VCS gelesen. Es scheint, als ob diese Funktion von Subversion es praktisch macht, zu bestimmen, wann ein Build (und eine resultierende Assembly) erstellt wird. –

Verwandte Themen