Kennt jemand BuildVersionIncrement

  • VB.NET

Es gibt 17 Antworten in diesem Thema. Der letzte Beitrag () ist von Renati.

    Kennt jemand BuildVersionIncrement

    Ich bin auf den BuildVersionIncrement (BVI) gestoßen, einen AddIn für Visual Studio, welches die Build Version automatisch hochzählt. Leider komme ich nicht ganz dahinter, wo er die Daten ablegt...

    Ich habe VB2010 und habe auch die Version BVI Version genommen, die dafür geeignet sein soll (v2.4.11046...). Das AddIn erscheit auch - so wie auch auf der Seite beschrieben - unter Extras. Einstellungen sind gemacht (siehe Dateianhang).

    Allerdings werden weder die Assemblyinformationen (Assembly und Dateiversion) noch die veröffentlich Version im Projekt hochgezählt.

    Kennt jemand das Tool und weiß wie ich an die Versionsdaten komme?
    Oder was ich falsch mache?

    Vielen Dank voraus und viele Grüße
    Tukuan
    Bilder

    • BVI.gif

      32,36 kB, 663×543, 197 mal angesehen

    Ist dieses BuildVersionIncrement-Tool sinnvoll?
    Du selbst solltest Herr der Versionsnummer Deines Programms sein.
    Solche Tools inkrementieren ggf. bei "zufälligem" Betätigen des Build-Buttons die Version, und schon hast Du Update-Aufwand.
    Das sollte nicht sein.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!

    RodFromGermany schrieb:

    Solche Tools inkrementieren ggf. bei "zufälligem" Betätigen des Build-Buttons die Version, und schon hast Du Update-Aufwand.
    Das sollte nicht sein.

    Hi,

    die Buildnummer gibt an, wie oft das Proramm compiled wurde. Selbst, wenn das nur aus Versehen passiert, ist dein Code compiled worden. Warum also nicht?

    nikeee
    Von meinem iPhone gesendet

    Weil dann 2 identische Programme mit unterschiedlicher Versionsnummer existieren.
    Wenn Du Software professionell entwickelst, insbesondere in einem Team, ist dies tödlich!
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!

    RodFromGermany schrieb:

    Weil dann 2 identische Programme mit unterschiedlicher Versionsnummer existieren.
    Soweit ich mich erinnern kann, wird der Code beim Klicken auf "Play" nur neu Compiled, wenn sich was am Quelltext verändert hat, andernfalls wird der Buidl davor zum Debuggen benutzt. Es kann aber passieren, dass man sich im Menü der Menülieste verklickt.


    RodFromGermany schrieb:

    Wenn Du Software professionell entwickelst, insbesondere in einem Team, ist dies tödlich!
    Nicht.

    Der Software professionell im Team entwickelt, lässt nicht alle am gleichem Projekt rumwurschteln, sondern nur an einem kleinen Teil, welcher selber Buidlnummern hat. Ab und zu wird dann mal nen kompletter Build gemacht.

    Schon mal die Buildnummern von Windows 8 gesehen?
    windows8beta.com/windows-8-builds
    Von meinem iPhone gesendet

    nikeee13 schrieb:

    Der Software professionell im Team entwickelt, lässt nicht alle am gleichem Projekt rumwurschteln, sondern nur an einem kleinen Teil, welcher selber Buidlnummern hat. Ab und zu wird dann mal nen kompletter Build gemacht.

    Ich sehe, Du hast noch nie professionell und schon gar nicht im Team Software entwickelt.
    Jedes Team-Mitglied hat alle Quellen des Projektes und muss während der Entwicklung auf den Build-Button drücken. Auch, wenn er nur an 2 von 1000 Files arbeitet.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!

    RodFromGermany schrieb:

    Ich sehe, Du hast noch nie professionell und schon gar nicht im Team Software entwickelt.
    Dann kläre mich bitte weiter auf.
    Wozu ist denn bitte eine Buildnummer da, wenn sie nicht die Nummer des Builds ist?
    Sicher, jeder entwickler kann das selbst bestimmen. Kläre mich bitte auf. Will alles wissen.

    Anscheinend bin ich ja nicht der Einzige, der komplett falsch informiert ist.
    maximiliankrauss.net/post/2009…n-des-Buildprozesses.aspx
    Von meinem iPhone gesendet

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „nikeee13“ ()

    RodFromGermany schrieb:

    und muss während der Entwicklung auf den Build-Button drücken. Auch, wenn er nur an 2 von 1000 Files arbeitet.

    Und?
    Die Datei, in der DIESE Information steht (Versionsnummer etc) ist doch eh' im source-control. Den stellt man dann ggf so ein, dass alle "Normalos" nur mit ner Kopie arbeiten, die nicht die im Safe vorhandene Version überschreibt.

    In großen Projekten ist es häufig der Fall, dass die einzelnen Entwicklergruppen sich das Komplettprojekt auschecken und ihre Teilprojekte lokal vorwärts treiben.
    Immer wenn ein brauchbarer Zwischenstand erreicht ist, werden die geänderten Sources wieder eingecheckt.
    Jede Nacht wird auf Basis der eingecheckten Quellen auf einem zentralen Build-Server der neue Build (mit der neuen Nummerierung) erzeugt.

    Ganz große Teilprojekte werden in "branches" ausgelagert, die erst nach Fertigstellung dem "trunc" wieder zugeführt werden.
    Hier ist so eine Variante grob beschrieben.
    --
    If Not Program.isWorking Then Code.Debug Else Code.DoNotTouch
    --

    YaPh1l schrieb:

    Wenn also in den Global Settings nichts eingestellt ist, dann passiert auch nichts.

    Bei Team-Entwicklung müssen schon alle dieselben Einstellungen haben, sonst knallt es irgendwo.
    Bei einer Tool-Automatisierung stehen dann ja bei den einzelnen Team-Mitgliedern verschiedene Nummern zu Buche.
    Wenn diese ins Source-Save kommen, kann es zu Konflikten kommen und man sollte darauf verzichten.
    Wenn diese nicht ins Source-Save kommen, ist es egal und man kann eh darauf verzichten.
    Üblicherweise wird bei einer Release-Auskoppelung eine Versionsnummer festgelegt.
    -------------------
    Also verzichten wir auf eine automatische Release-Numerierung.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!

    Funktion nicht Sinn war gefragt

    Moin Forum,
    vielen Dank für die Antworten... UND ich weiß es zu schätzen, dass ihr auch über den Sinn diskutiert...
    Kann sein, dass es für viele Projekte keinen Sinn macht.
    Aber wir arbeiten zu 2 an einem Projekt und dann meistens nicht mal gleichzeitig...
    Da wir demnächst unsere Kollegen bitten wollen Betatester zu spielen und ich meinen Kollegen und mich kenne, die gerne vergessen die Nummer hochzusezten, fand ich das Tool nicht schlecht.

    @Topic:

    YaPh1l schrieb:

    Du hast Global Settings auf True. Soweit ich weiß, ignoriert BVI dann alle projekt-bezogenen Einstellungen. Wenn also in den Global Settings nichts eingestellt ist, dann passiert auch nichts.
    Ich habe die Einstellung geändert. Es passiert leider immer noch nichts bzw. ich weiß nicht wie ich daran komme. Also die Einstellungen im Projekt werden jedenfalls nicht geändert...

    Gruß
    Tukuan

    Tukuan schrieb:

    Aber wir arbeiten zu 2 an einem Projekt und dann meistens nicht mal gleichzeitig...

    Genau das ist das Problem.
    Arbeitet Ihr am selben Rechner?
    Habt Ihr eine Sourcecode-Verwaltung?
    Was passiert, wenn ein Tester sagt, mit Version 1.2.3.4 gibt es Probleme - könnt Ihr den Quellenstand dazu restaurieren?
    Habt Ihr eine Verfahrensanweisung, wie mit (Beta-)Versionen unzugehen ist?
    usw.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!

    Ich weiß was du meinst...

    Aber ein Autoincrement finde ich besser als es immer mal wieder zu vergessen, die Versionsnummer nochzuzählen, oder?
    Leider nutzen wir noch keine Sourcecode-Verwaltung - weil unsere IT nicht zu rande kommt, den Server zu installieren... :(

    Vielleicht hast du ja aber auch recht...

    Wie gesagt, fand das Tool nicht schlecht. Leider funktioniert es nicht bzw. ich komme an das Ergebnis nicht ran. Somit muss ich es wohl es anders machen.

    Hat jemand Tips?

    Danke
    Gruß
    Tukuan

    Lass Dein Build über eine Batch-Datei laufen,
    mach eine Ausgabe: Build-Nummer vorgeben: (letzte Nummer) oder
    schreib Dir selbst ein kleines Programm, dass die Nummer an den richtigen Stellen einträgt.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!

    Renati schrieb:

    Du musst bei dem entsprechenden Programm an den entsprechenden Stellen, die hochgezählt werden sollen, ein "*" eintragen.

    Ja und?
    Mehrere Leute arbeiten an denselben Quellen, und was kommt da raus?
    Zumindest Inkonsistenz.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!

    Also selbst bei einer denkbar schlechten Konfiguration entstehen Inkonsistenzen allenfalls durch ein miserables Versionskontrollsystem wie CVS oder SVN. Wer das heute noch benutzt, hat durch dessen Unzulänglichkeiten eh schon mehr Ärger als Nutzen. In allen anderen Fällen bringt einem das halt nur einen erhöhten Commit-Aufwand.
    Wenn man das Plugin hingegen richtig, d.h. nicht wild verteilt durch die ganze Entwicklergemeinde, nutzt, kann es äußerst nützlich sein.

Facebook
Telefonspende