2010-03-09 4 views
5


Ich erstelle eine C# -Lösung in Visual Studio 2008 mit mehreren Projekten und Projektabhängigkeiten.
Ich suche nach einer Möglichkeit, DLL-Versionsnummern nur ändern, wenn der Code, der das Projekt erstellt, ändert.

Ich verwende derzeit Beyond Compare, um meine lokal erstellte Version mit dem Produktionsdateisystem zu vergleichen. Das Ziel besteht darin, NUR aktualisierte DLLs bereitzustellen. Ich verwende autoinkrementierende Versionsnummern, und jedes Mal, wenn Sie Visual Studio öffnen und einen Build ausführen, werden alle DLL-Versionsnummern erhöht. Das Gleiche gilt für eine vollständige Neuerstellung und wenn ein anderer Entwickler einen Build erstellt und versucht, ihn zu implementieren.

Gibt es eine Möglichkeit, Visual Studio zu konfigurieren, NUR die Build-Nummer basierend auf geänderten Dateiinhalten zu erhöhen? Gibt es einen Zusatz, der das tut?

Es scheint, dass ein Binärvergleich dieser Dateien auch wegen der unterschiedlichen Versionsnummern in den DLLs fehlschlägt. Kennt jemand ein besseres Werkzeug, vergleichen Sie nur den Inhalt von dlls?

Vielen Dank im Voraus.So konfigurieren Sie Build-Nummern in Visual Studio zum Aktivieren des DLL-Vergleichs

Antwort

1

Eine Option ist der Übergang zu einer kontinuierlichen Integrationslösung wie Cruise Control .Net, mit der Builds beim Einchecken in ein Quellcodeverwaltungssystem ausgelöst werden können.

In Bezug auf Montage Versionierung, was ich in der Regel tun, ist eine einzige SolutionVersion.cs erstellen (um die Standard-Montageversion cs zu ersetzen), die für jedes Projekt verknüpft ist (verwenden Sie das vorhandene Element hinzufügen, aber die Schaltfläche als Link hinzufügen ändern)

Dann benutze ich eine NAnt oder MSBuild Aufgabe, den Tempomat Build-Label Nummer zu nehmen und die SolutionVersion.cs verison Zahlen überschreiben, bevor die Lösung

auf diese Weise gebaut wird ich eine Versammlung nehmen und verfolgen es zurück an den Code über CruiseControl Build-Version (noch besser, ich bekomme normalerweise CC.net, um die Quelle mit der gleichen Nummer in der Quellcodeverwaltung zu kennzeichnen)

+0

+1 für ccnet. Für Assembly-Versionen verwenden wir die Subversion-Revisionsnummer.Für die Installationsprogramme haben wir ccnet-Projekte, die einen Force-Build erfordern, so dass das Installationsprogramm basierend auf der ccnet-Build-Nummer versioniert wird. – Pedro

+0

Sie haben Recht, mit dem Build-Server ist dies die beste Option. Die Datei mit der verknüpften Version bekommt den größten Teil des Weges dorthin, aber jede DLL-Version würde sich mit jedem Build ändern, wenn Sie die Build-Nummer verwenden. Die Verwendung der rev-Nummer aus der Quellcodeverwaltung scheint in den meisten Szenarios komplizierter zu sein, und die Komplexität der letzten rev-nummern nur für Dateien in einem bestimmten Projekt zu erhöhen. – jaminto

+0

ich gebe die Anforderung der teilweisen Bereitstellung von nur aktualisierten DLLs auf, die Bereitstellung aller DLLs aus einem neuen Build ist in Ordnung, und alle haben aktualisierte Versionsnummern basierend auf der Build-Nummer. http://www.jetbrains.com/teamcity/ ist jetzt mein Buildserver der Wahl, vielleicht auch deiner. – jaminto

0

Es ist nicht ganz das, was Sie fragen, aber ich fand dies hilfreich im Umgang mit großen Lösungen: Versioning Controlled Build. Gemäß seinem Dokument erkennt es die Änderungen, an denen Sie interessiert sind: "Wenn es eine Datei mit einem neueren Zeitstempel gibt (was bedeutet, dass der Quellcode nach der vorherigen Versionsänderung geändert wurde), wird das Projekt für die Versionsaktualisierung markiert . "

Die empfohlene, unterstützbare Lösung wäre, dass Ihr Projekt die Build-Nummer nicht automatisch im Visual Studio-Modus inkrementiert. Dann müssten Sie manuell ein Skript für den Build vor dem Build/MS erstellen, um das Inkrement auszuführen.

0

Es gibt eine interessante Probe in diesem codeproject article was Sie es heraus überprüfen sollten, ... es beinhaltet eine vorkompilierte Aufgabe, die macht die Aufgabe, die Build-Nummer der Aktualisierung basierend auf dem Tag des Jahres

0

würde ich vorschlagen, dass Sie prüfen die Optionen, die das Revisionskontrollsystem bereitstellt, um Revisionsinformationen in Quelldateien einzubetten. Ich hatte in der Vergangenheit schon genug Probleme mit Autoinkremen, die ich mir nie wieder versprach. Heutzutage bevorzuge ich etwas, das ein wenig konkreter ist als eine Build-Nummer, und verbinde eindeutige Bezeichner in jedes Produkt des Build-Systems.

Ich beschreibe mein eigenes System in Embedding mercurial revision information in Visual Studio c# projects automatically. Während meine Lösung wahrscheinlich nicht für Sie geeignet ist, wurden andere interessante Optionen als Antwort auf meine Frage vorgeschlagen, so dass einige der Lösungen, die ich abgelehnt habe, dennoch für Sie nützlich sein könnten, selbst wenn Sie sie an Ihr VCS anpassen müssen benutzen.

Verwandte Themen