Mettre à jour automatiquement le numéro de version

Je souhaite que la propriété version de mon application soit incrémentée pour chaque génération, mais je ne suis pas sûr de savoir comment activer cette fonctionnalité dans Visual Studio (2005/2008). J'ai essayé de spécifier le AssemblyVersion comme 1.0. * Mais il ne me comprends pas exactement ce que je veux.

J'utilise également un fichier de paramètres et dans les tentatives antérieures lorsque la version de l'ensemble a changé mes paramètres ont été réinitialisés à la valeur par défaut depuis que l'application a cherché le fichier de paramètres dans un autre répertoire.

Je voudrais être en mesure d'afficher un numéro de version sous la forme de 1.1.38 donc quand un utilisateur trouve un problème, je peux enregistrer la version qu'ils utilisent ainsi que leur dire de mettre à niveau s'ils ont une ancienne version.

Une brève explication de la façon dont le travail de version serait également apprécié. Quand le numéro de build et de révision est-il incrémenté?

0
ajouté édité
Vues: 3
La question suivante propose une solution simple et pratique pour injecter un numéro de build dans votre application en générant un fichier source dans un événement de génération. stackoverflow.com/questions/4450231/…
ajouté l'auteur Ashley Davis, source

11 Réponses

According to Wikipedia: "[Game Boy's] monochrome screen, lack of a backlight, and less powerful hardware" is at the root of the problem.

9
ajouté
Wow, j'ai réussi à survoler complètement cela quand je lisais l'article.
ajouté l'auteur Joshua McKinnon, source
En plus, alors que les résolutions étaient les mêmes, le Gear avait un écran plus grand (3.2 "vs 2.6"), ce qui a probablement contribué aussi.
ajouté l'auteur André Paramés, source

La faible autonomie de la Sega Game Gear est due au rétroéclairage de l'écran. C'est un tube fluorescent qui mange les piles à un rythme rapide. Récemment, plusieurs personnes ont expérimenté le remplacement du tube fluorescent par des LED, ce qui augmente considérablement la durée de vie de la batterie, prouvant ainsi que l'alimentation principale provient du rétro-éclairage.

5
ajouté

Je crois comprendre que les écrans LCD couleur de l'époque étaient essentiellement de gros porcs énergétiques. Tous les autres ordinateurs de poche en couleur concurrençant le Game Boy original ont souffert du même problème. Ceux qui ont offert le rétro-éclairage ont également souffert d'un drain de puissance similaire là-bas.

Je ne peux pas commenter la question de la consommation d'énergie des chipsets, mais c'était probablement un problème aussi.

5
ajouté
Le rétro-éclairage était le plus grand coupable, je pense.
ajouté l'auteur Shinrai, source

Je pense que la vie de la batterie concerne l'allocation de la mémoire de la cartouche de jeu: elle est vraiment grande parfois, mais très rarement en jouant (par exemple, Sonic the Hedgehog ).

En outre, la couleur et la batterie dure plus de 5 heures est une blague.

modifier

Ce que je veux dire est que, dans certains jeux, il utilise beaucoup de mémoire de la cartouche et s'il y a beaucoup de couleurs, il draine rapidement les batteries: il est une question de combien de pixels, les couleurs, et la mémoire est chargée. Ceci est facilement perceptible lorsque le jeu ralentit.

3
ajouté
J'ai essayé de lire cette réponse plusieurs fois, mais je n'arrive toujours pas à comprendre ce que vous entendez par "la vie de la batterie concerne le jeu. La mémoire allouée est vraiment grande parfois, mais très rarement en jouant"
ajouté l'auteur Denilson Sá Maia, source
Qu'est-ce que je veux dire est que dans certains jeux, il charge parfois beaucoup de mémoire de la cartouche et si theres allot de couleurs il a bu des batteries rapidement! C'est en fait combien de pixels, les couleurs et la mémoire sont chargés. jeu ralentit et est très lent! PM moi maintenant si vous ne comprenez pas! EDIT: A propos de ralentissements vous allez les voir très souvent en sonic 1 pour les engins de jeu! Selon AllieRX87 sa détection de collision appelée!
ajouté l'auteur TheAnimeMurder, source
bonjour juppoter agréable de vous avoir sur le spectacle! Connaissez-vous Frauber le super mario 64 hacker! Si vous le faites! dites-lui de monter sur ce forum pour parler de certains hacks!
ajouté l'auteur TheAnimeMurder, source
lis la réponse que j'ai entrée!
ajouté l'auteur TheAnimeMurder, source
Salut TheAnimeMurder, bienvenue au jeu! Je suis allé de l'avant et incorporé votre deuxième réponse ici: si vous voulez élargir votre réponse, il suffit de cliquer sur le lien "modifier" ci-dessous.
ajouté l'auteur user3389, source
Je suis sûr que cette réponse est incorrecte. La quantité de mémoire ROM n'aura aucune importance pour l'alimentation. Si la mémoire volatile était DRAM, la consommation d'énergie n'est pas liée à la quantité de mémoire utilisée par le jeu. Si c'était SRAM, alors la consommation serait fonction du nombre de fois que chaque bit change. Mais, encore, ce n'est pas la principale raison de la grande fuite d'énergie. Je crois que les circuits numériques ont drainé relativement peu de courant, alors que l'écran LCD et le rétroéclairage drainaient beaucoup plus (charge résistive).
ajouté l'auteur Denilson Sá Maia, source

Avec le contenu "Built in", vous ne pouvez pas, en utilisant 1.0. * Ou 1.0.0. *, Remplacer les numéros de révision et de compilation par une date / horodatage codée, ce qui est généralement aussi un bon moyen.

Pour plus d'informations, consultez la Assembly Linker Documentation dans la balise / v.

En ce qui concerne l'incrémentation automatique des nombres, utilisez la tâche AssemblyInfo:

Tâche AssemblyInfo

Cela peut être configuré pour incrémenter automatiquement le numéro de build.

Il y a 2 Gotchas:

  1. Each of the 4 numbers in the Version string is limited to 65535. This is a Windows Limitation and unlikely to get fixed.
  2. Using with with Subversion requires a small change:

Récupérer le numéro de version est alors assez facile:

Version v = Assembly.GetExecutingAssembly().GetName().Version;
string About = string.Format(CultureInfo.InvariantCulture, @"YourApp Version {0}.{1}.{2} (r{3})", v.Major, v.Minor, v.Build, v.Revision);

Et, pour clarifier: In .net ou au moins en C#, la construction est en fait le troisième numéro, pas le quatrième comme certaines personnes (par exemple Delphi Developers qui sont habitués à Major.Minor.Release.Build) peuvent s'attendre.

En .net, c'est Major.Minor.Build.Revision.

0
ajouté
@Jugglingnutcase - ce lien serait presque parfait, si cela a fonctionné pour les versions actuelles de Visual Studio
ajouté l'auteur Kraang Prime, source
@Michael Stum: Pourriez-vous mettre à jour le lien tâche AssemblyInfo dans votre réponse s'il vous plaît? Pour moi, il ne se charge pas correctement.
ajouté l'auteur Matt, source
Je viens de trouver ce complément de studio visuel qui fait quelque chose de similaire: autobuildversion.codeplex.com
ajouté l'auteur jrsconfitto, source
@SanuelJackson haha! Oui, ça le serait. dommage que je ne sois pas au courant de mes commentaires de 2010, désolé! : P La marche du temps et des versions nous attriste tous.
ajouté l'auteur jrsconfitto, source
Cela signifie-t-il que le 4 juin 2179 les numéros de version par défaut de Microsoft vont se casser? (le 65536ème jour après 2000)
ajouté l'auteur ThePower, source
Le lien "AssemblyInfo Task" ne fonctionne pas
ajouté l'auteur Alexandre Cavaloti, source

Il y a quelque temps, j'ai écrit un exe rapide et sale qui mettrait à jour le numéro de la version dans un assemblyinfo. {Cs / vb} - J'ai aussi utilisé rxfind.exe (un outil de remplacement de recherche regex simple et puissant) pour faire mise à jour à partir d'une ligne de commande dans le cadre du processus de construction. Quelques autres conseils utiles:

  1. separate the assemblyinfo into product parts (company name, version, etc.) and assembly specific parts (assembly name etc.). See here
  2. Also - i use subversion, so I found it helpful to set the build number to subversion revision number thereby making it really easy to always get back to the codebase that generated the assembly (e.g. 1.4.100.1502 was built from revision 1502).
0
ajouté
Si c'est pour un fichier de code ( .cs / .vb), vous devriez utiliser un template T4 à la place.
ajouté l'auteur BrainSlugs83, source

J'ai trouvé que cela fonctionne bien d'afficher simplement la date de la dernière construction en utilisant ce qui suit partout où une version du produit est nécessaire:

System.IO.File.GetLastWriteTime(System.Reflection.Assembly.GetExecutingAssembly().Location).ToString("yyyy.MM.dd.HH.mm.ss")

Plutôt que d'essayer d'obtenir la version de quelque chose comme ceci:

System.Reflection.Assembly assembly = System.Reflection.Assembly.GetExecutingAssembly();
object[] attributes = assembly.GetCustomAttributes(typeof(System.Reflection.AssemblyFileVersionAttribute), false);
object attribute = null;

if (attributes.Length > 0)
{
    attribute = attributes[0] as System.Reflection.AssemblyFileVersionAttribute;
}
0
ajouté
Je pense que vous voulez dire ceci: yyyy.MM.dd.HHmm pas yyyy.MM.dd.HHMM.
ajouté l'auteur JHubbard80, source

Quel système de contrôle de source utilisez-vous?

Presque tous ont une forme de $ Id $ tag qui se développe quand le fichier est archivé.

J'utilise généralement une forme de hackery pour l'afficher comme numéro de version.

L'autre alternative est l'utilisation de la date comme numéro de build: 080803-1448

0
ajouté
Pouvez-vous développer «Presque tous ont une forme de $ Id $ tag qui se développe lorsque le fichier est archivé». Plus précisément, savez-vous pour subversiion?
ajouté l'auteur Greg B, source

VS.NET utilise par défaut la version d'assembly à 1.0. * Et utilise la logique suivante lors de l'incrémentation automatique: il définit la partie de construction au nombre de jours depuis le 1er janvier 2000 et définit la partie de révision sur le nombre de secondes depuis minuit, heure locale, divisée par deux. Consultez cet article MSDN .

La version d'assembly se trouve dans un fichier assemblyinfo.vb ou assemblyinfo.cs. Du fichier:

' Version information for an assembly consists of the following four values:
'
'      Major Version
'      Minor Version 
'      Build Number
'      Revision
'
' You can specify all the values or you can default the Build and Revision Numbers 
' by using the '*' as shown below:
'  

 
 
0
ajouté
Merci d'inclure la date initiale: 1er janvier 2000
ajouté l'auteur kiewic, source

Si vous voulez un numéro d'incrémentation automatique qui se met à jour chaque fois qu'une compilation est effectuée, vous pouvez utiliser VersionUpdater de un événement de pré-construction. Votre événement de pré-construction peut vérifier la configuration de construction si vous préférez, afin que le numéro de version ne soit incrémenté que pour une version Release (par exemple).

0
ajouté
Intéressant. J'ai eu le mien depuis des années avec le même nom et je ne savais pas qu'il existait (même si je l'ai juste mis en ligne récemment): github.com/rjamesnw/VersionUpdater
ajouté l'auteur James Wilkins, source

[Visual Studio 2017, .csproj propriétés]

Pour mettre à jour automatiquement votre propriété PackageVersion / Version / AssemblyVersion (ou toute autre propriété), créez d'abord une nouvelle classe Microsoft.Build.Utilities.Task qui obtiendra votre numéro de build actuel et renverra le numéro mis à jour (Je recommande de créer un projet séparé juste pour cette classe).

Je mets à jour manuellement les numéros major.minor, mais laisse MSBuild mettre à jour automatiquement le numéro de build (1.1. 1 , 1.1. 2 , 1.1. 3 , etc. :)

using Microsoft.Build.Framework;
using System;
using System.Collections.Generic;
using System.Text;

public class RefreshVersion : Microsoft.Build.Utilities.Task
{
    [Output]
    public string NewVersionString { get; set; }
    public string CurrentVersionString { get; set; } 

    public override bool Execute()
    {       
        Version currentVersion = new Version(CurrentVersionString ?? "1.0.0");

        DateTime d = DateTime.Now;
        NewVersionString = new Version(currentVersion.Major, 
            currentVersion.Minor, currentVersion.Build+1).ToString();
        return true;
    }

}

Ensuite, appelez votre processus Task on MSBuild récemment créé en ajoutant le code suivant sur votre fichier .csproj:

    
...


   
                       
   
   
   

...

 ..
 1.1.4
 ..

Lorsque vous choisissez l'option de projet Visual Studio Pack (il suffit de passer à BeforeTargets = "Build" pour exécuter la tâche avant Build), le code RefreshVersion sera déclenché pour calculer le nouveau numéro de version, et XmlPoke task va mettre à jour votre propriété .csproj en conséquence (oui, il va modifier le fichier).

Lorsque je travaille avec des bibliothèques NuGet, j'envoie également le paquet au référentiel NuGet en ajoutant simplement la tâche de compilation suivante à l'exemple précédent.



c:\nuget\nuget is where I have the NuGet client (remember to save your NuGet API key by calling nuget SetApiKey or to include the key on the NuGet push call).

Juste au cas où ça aiderait quelqu'un ^ _ ^.

0
ajouté