Discussion :

[BasicZX81]

Bonsoir à tous,
Je me permets de poser la question ici car je n'ai pas obtenu de réponse dans la section "Visual Studio" du forum.

Les opérations que je souhaite faire sont simple et pourtant je suis complètement perdu avec cet outil qui est nouveau pour moi, j'avais l'habitude d'utiliser svn avant pour enregistrer les différentes révisions de mon code.
Comment faire la même chose que je faisais avant sur svn ? A savoir :

1: Dés que j'ai fini d'apporter les modifications à mon code je consulte svn pour obtenir le dernier numéro de révision utilisé.
2: Puis je mets à jour le Chanlog de mon programme avec le numéro de révision n+1 obtenu. (Je précise que je suis tout seul à travailler sur mon code donc les numéros se suivent, je n'ai jamais de surprise).
3: Une fois que j'ai changer le Changelog, j'upload les modifications sur le serveur svn, et voilà c'est fini....

Avec Team Explorer, je ne sais pas du tout comment procéder de la sorte, je vois des numéros "ensembles de modifications" qui ne semblent pas correspondre à un numéro de version.....comment obtenir ces fameux numéros de révision, comment les consulter, comment sont t'ils incrémentés......etc....

Bref, je suis complètement perdu et je vous remercie beaucoup si vous pouvez m'aider.....

[DotNetMatt]

Les terminologies sont différentes. Première question, utilises-tu TFS (Team Foundation Server, on-premises) ou bien TFS (Team Foundation Services, la version cloud, aussi appelée Visual Studio Online) ? En quelle version ?

Ce qui est commun, c'est que quand tu commit ton code on appelle ca un Change Set (ensemble de modifications en Francais). Chaque Change Set a un numéro incrémenté automatiquement lors du commit (incrément de +1).

Pour les consulter tu peux aller sur le portail web, dans ton projet, ensuite tu peux retrouver l'historique des change set et voir le code qui a été archivé dans l'onglet Code. Tu peux aussi comparer les versions, commenter, etc.

C'est ce que tu cherches ?

[BasicZX81]

Merci de me répondre DotNetMatt,

Les terminologies sont différentes. Première question, utilises-tu TFS (Team Foundation Server, on-premises) ou bien TFS (Team Foundation Services, la version cloud, aussi appelée Visual Studio Online) ? En quelle version ?

Alors en fait, je ne sais pas faire la différence. Je suppose que j'utilise Team Foundation Services puisque j'ai ce message qui s'affiche dans la fenêtre de sortie : Impossible de compléter automatiquement vos comptes Team Foundation Service. Et ce que je voulais faire au départ c'est de me débarrasser d'outils tiers comme
TortoiseSVN et de mon Serveur SVN perso au profit de l'utilisation des outils intégrés à Visual Studio Ultimate 2013 et avec les avantages du Cloud.
La version de Team Foundation Services ? Ben je ne la connais pas, mon compte s'est crée en 2 cliques à partir de VS et d'un compte xxxx@live.fr.
A chaque fois que je veux ajouter une solution au controle de code source, VS me propose : Contrôle de version Team Foundation ou Git. Je choisi à chaque fois le 1er puisque c'est celui par défaut et que j'ai encore moins compris le fonctionnement de Git.

Ce qui est commun, c'est que quand tu commit ton code on appelle ça un Change Set (ensemble de modifications en Francais). Chaque Change Set a un numéro incrémenté automatiquement lors du commit (incrément de +1).

Oui, j'ai vu ça (les ensembles de modifications). J'ai déjà plein "Change Set" sur différents "différentes solutions" contenus dans différents "projets d'équipes". Ce qui me perturbe c'est que ce numéro semble s'incrémenter non pas à partir des Commit effectués sur une solution mais aussi à partir des Commit effectués sur d'autres solutions voir même d'autres projets d'équipes. Je me trompe peut-être mais au vue du fonctionnement de cet incrément je me dit que ce n'est pas ce numéro là qui m'interresse.
Ex: Je voudrais un numéro de version qui évolue indépendamment sur chaque solution, Cela fonctionnait comme ça sur SVN, c'est possible de faire la même chose ?. (A moins que je ne comprenne pas la notion de projets d'équipe contenant plusieurs solutions auquel cas je veux bien une explication).

Pour les consulter tu peux aller sur le portail web, dans ton projet, ensuite tu peux retrouver l'historique des change set et voir le code qui a été archivé dans l'onglet Code. Tu peux aussi comparer les versions, commenter, etc.

Sauf si je suis obligé pour certaines opérations plus avancées, je passerais sur le portail Web mais on doit pouvoir faire des commits et consulter l'historique des versions depuis Team Explorer de Visual Studio non ? En tous cas je ne voudrais faire que des opérations simple que j'ai cité à partir de Team Explorer pour l'instant (si c'est possible).

C'est ce que tu cherches ?

Presque

EDIT : Bon, apriori j'utilise Team Foundation Serveur (mais sans certitude).
Je me pose des questions aussi sur le mappage correcte des dossiers, ça fait partie d'une mauvaise compréhension de ma part et qui amène des interrogations :
http://www.developpez.net/forums/d15...mplacement-tf/

[DotNetMatt]

Alors en fait, je ne sais pas faire la différence. Je suppose que j'utilise Team Foundation Services puisque j'ai ce message qui s'affiche dans la fenêtre de sortie : Impossible de compléter automatiquement vos comptes Team Foundation Service. Et ce que je voulais faire au départ c'est de me débarrasser d'outils tiers comme
TortoiseSVN et de mon Serveur SVN perso au profit de l'utilisation des outils intégrés à Visual Studio Ultimate 2013 et avec les avantages du Cloud.
La version de Team Foundation Services ? Ben je ne la connais pas, mon compte s'est crée en 2 cliques à partir de VS et d'un compte xxxx@live.fr.
A chaque fois que je veux ajouter une solution au controle de code source, VS me propose : Contrôle de version Team Foundation ou Git. Je choisi à chaque fois le 1er puisque c'est celui par défaut et que j'ai encore moins compris le fonctionnement de Git.

En effet ca a l'air d'être la version online. Pour en etre sûr, tu peux regarder l'URL que tu utilises pour te connecter à ton serveur. Si elle se termine par "visualstudio.com" c'est bien cela. Pour info c'est actuellement en version 2013.

Oui, j'ai vu ça (les ensembles de modifications). J'ai déjà plein "Change Set" sur différents "différentes solutions" contenus dans différents "projets d'équipes". Ce qui me perturbe c'est que ce numéro semble s'incrémenter non pas à partir des Commit effectués sur une solution mais aussi à partir des Commit effectués sur d'autres solutions voir même d'autres projets d'équipes. Je me trompe peut-être mais au vue du fonctionnement de cet incrément je me dit que ce n'est pas ce numéro là qui m'interresse.
Ex: Je voudrais un numéro de version qui évolue indépendamment sur chaque solution, Cela fonctionnait comme ça sur SVN, c'est possible de faire la même chose ?. (A moins que je ne comprenne pas la notion de projets d'équipe contenant plusieurs solutions auquel cas je veux bien une explication).

En effet ce n'est pas fait pour cela. La gestion des numéros de version n'est pas gérée par le gestionnaire de codes sources mais par le contrôleur de build. Le Change Set c'est juste équivalent à un commit. Il y a un numéro attribué pour pouvoir retrouver et identifier chaque commit et non pour identifier les versions (car on peut avoir des milliers de commit pour une seule évolution de version). A chaque build le numéro est incrémenté (quand le code source est complié par le serveur de build). TFS intègre nativement un tel gestionnaire basé sur MSBuild. A toi de voir si tu veux l'utiliser ou non Si non, tu dois trouver une autre facon de faire cela, et google fourmille de possibilités... Tu peux chercher "vb.net version number auto increment". Je t'invite à te documenter sur l'ALM (Application Lifecycle Management) car il faut au moins en connaitre les bases pour pouvoir l'utiliser correctement Il y a un monde entre SVN et TFS, même si les notions sous-jacentes sont les mêmes. Tu peux déjà commencer par les ALM Rangers.

Sauf si je suis obligé pour certaines opérations plus avancées, je passerais sur le portail Web mais on doit pouvoir faire des commits et consulter l'historique des versions depuis Team Explorer de Visual Studio non ? En tous cas je ne voudrais faire que des opérations simple que j'ai cité à partir de Team Explorer pour l'instant (si c'est possible).

On peut faire beaucoup de choses avec Team Explorer, mais pas tout. Et Team Explorer va te rediriger vers le portail web pour consulter par exemple l'historique des change sets. Ce que tu peux faire dans VS, c'est faire un click droit sur un fichier puis aller dans Source Control > View History (désolé je n'ai pas VS en Francais). Ensuite tu peux retrouver les infos sur ce change set en faisant un click droit sur celui qui t'intéresse puis aller dans Change set details. Mais bon ce n'est pas aussi ergonomique que par le portail web donc à toi de voir.

[BasicZX81]

En effet ca a l'air d'être la version online. Pour en etre sûr, tu peux regarder l'URL que tu utilises pour te connecter à ton serveur. Si elle se termine par "visualstudio.com" c'est bien cela. Pour info c'est actuellement en version 2013.

Ça se termine bien par visualstudio.com

En effet ce n'est pas fait pour cela. La gestion des numéros de version n'est pas gérée par le gestionnaire de codes sources mais par le contrôleur de build. Le Change Set c'est juste équivalent à un commit. Il y a un numéro attribué pour pouvoir retrouver et identifier chaque commit et non pour identifier les versions (car on peut avoir des milliers de commit pour une seule évolution de version). A chaque build le numéro est incrémenté (quand le code source est complié par le serveur de build). TFS intègre nativement un tel gestionnaire basé sur MSBuild. A toi de voir si tu veux l'utiliser ou non Si non, tu dois trouver une autre facon de faire cela, et google fourmille de possibilités... Tu peux chercher "vb.net version number auto increment". Je t'invite à te documenter sur l'ALM (Application Lifecycle Management) car il faut au moins en connaitre les bases pour pouvoir l'utiliser correctement Il y a un monde entre SVN et TFS, même si les notions sous-jacentes sont les mêmes. Tu peux déjà commencer par les ALM Rangers.

Merci beaucoup pour ces renseignements, j'ai pu investiguer un peu plus et, j'avoue que je suis encore un peu noyé....
- On a d'un coté des numéros de ChangeSet qui s’incrémentent après un commit sur des changements en attente qui couvrent l'ensemble des projets d'équipe (pas forcement lié aux projets qui me concerne....)
- On a des numéros de Build dont on peux définir le format. Le format par défaut étant : $(BuildDefinitionName)_$(Date:yyyyMMdd)$(Rev:.r)
- On a le format de type a.b.c.d (a pour version majeur, b pour version mineur, c pour build, et d pour révision) à renseigner dans la fenêtre Propriété du Projet/Application/Version de l'assembly... . On peux retrouver ces mêmes numéros dans les propriétés des fichiers exe une fois compilé. On peux aussi laisser Visual Studio incrémenter c et d à chaque génération de solution (en modifiant le fichier AssemblyInfo.vb ou cs) mais j'ai pas l'impression qu'il y a un lien avec TFS.

Voilà pour ce que j'ai vus, mais le truc c'est que j'ai l'impression que tous ces numéros vivent chacun dans leur coin sans qu'il n'y ai vraiment de rapport entre eux ou avec TFS et avec notamment la possibilité de renseigner le format de type a.b.c.d. automatiquement (ou même manuellement) à partir d'un ou plusieurs numéros obtenus depuis le serveur de contrôle de code source.

Est ce que le code $Rev:.r peux répondre à mes attentes ? Je pourrais peux être le placer dans c ou d ?

Je précise que je ne cherche pas à faire quelque chose de compliqué, juste pouvoir retrouver/consulter/restaurer un code source (placé dans le cloud) de façon relativement fiable et à partir d'un identifiant obtenu à partir des propriétés des fichiers exe (autrement dit le format a.b.c.d) même si pour cela je ne dois utiliser que la lettre d (comme je faisais avant par exemple). Comment faire cela ? Même si je doit le mettre à la main ça ne me dérange pas (sinon le mieux serait que TFS gère tous ça pour moi). Peut-être pouvez vous me conseiller la dessus.

Je suis peut-être dans l'erreur, c'est pour ça que je m'adresse à vous et désolé pour toutes ces questions mais je suis très loin d'avoir le niveau professionnel de la plupart d'entre vous sur ce forum.

[DotNetMatt]

Voilà pour ce que j'ai vus, mais le truc c'est que j'ai l'impression que tous ces numéros vivent chacun dans leur coin sans qu'il n'y ai vraiment de rapport entre eux ou avec TFS et avec notamment la possibilité de renseigner le format de type a.b.c.d. automatiquement (ou même manuellement) à partir d'un ou plusieurs numéros obtenus depuis le serveur de contrôle de code source.

Tu as tout compris, le versionning étant propre à chaque projet, il n'existe aucune règle. C'est à toi et à toi seul de créer tes règles et on ne peut pas le faire à ta place car on ne connait pas ton budget, tes ressources, l'architecture générale, le besoin final précis, etc. (c'est pour cela qu'on ne peut malheureusement pas t'aider beaucoup plus). C'est un peu comme en architecture : il y a des bonnes pratiques mais ensuite tout est possible et il existe une infinité de combinaisons possibles.

Je précise que je ne cherche pas à faire quelque chose de compliqué, juste pouvoir retrouver/consulter/restaurer un code source (placé dans le cloud) de façon relativement fiable et à partir d'un identifiant obtenu à partir des propriétés des fichiers exe (autrement dit le format a.b.c.d) même si pour cela je ne dois utiliser que la lettre d (comme je faisais avant par exemple). Comment faire cela ? Même si je doit le mettre à la main ça ne me dérange pas (sinon le mieux serait que TFS gère tous ça pour moi). Peut-être pouvez vous me conseiller la dessus.

Encore une fois difficile de t'aider précisément... Tu dois d'abord décider si tu veux utiliser le serveur de build de TFS ou si les build de Visual Studio te suffisent. Ensuite tu pourras déjà décider si tu dois t'intéresser en profondeur à MSBuild et à comment est-ce que TFS génère les livrables, ou si tu dois juste t'intéresser à la manière de gérer cela dans Visual Studio.

Ce qui est sûr c'est que tu ne dois pas te baser sur le numéro du Change Set. Après tu peux aussi avoir une table SQL ou un fichier XML qui fait référence à ce numéro, mais comme on ne connait rien à ton projet ce sont peut-être de mauvaises pistes. Et en ce qui concerne l'ALM il ne suffit pas de passer quelques heures pour avoir les clés en main. Le mieux c'est de faire des tests et de voir ce qui te convient le mieux. On pourra mieux te guider sur des questions plus précises.

Je suis peut-être dans l'erreur, c'est pour ça que je m'adresse à vous et désolé pour toutes ces questions mais je suis très loin d'avoir le niveau professionnel de la plupart d'entre vous sur ce forum.

Pas d'inquiétude à avoir, le forum est fait pour cela

[BasicZX81]

Bonsoir, merci DotNetMatt
Je suis rentré dans le vif du sujet en faisant quelque manip sur un Projet Bac à sable.....(WindowsApplication1)
J'ai crée 3 builds et je vois bien un numéro qui s'incrémente sur chacun d'eux....par contre pour chacune des Builds je m'attendais à obtenir un fichier exe compilé hors je ne vois aucun changement dans le répertoire Bin/Debug de la solution.
Et dans le résumé des 3 opérations j'ai ce message : $/WindowsApplication1/WindowsApplication1/WindowsApplication1.sln compilé, mais je ne sais pas du tout en fait à quoi consiste ces Builds....
Qu'est ce qu'on peux faire avec ces 3 Builds crées en fait ?

Pour répondre au message d'avant , je programme tous seul pour mon loisir et ça me sert un peu pour mon travail de tous les jours, je n'ai aucune exigence particulière sauf le soucis de savoir ou j'en suis dans les évolutions de code et j'aime bien garder la traçabilité de ce que je fait sous la forme d'un fichier texte Changlog qui reprend des numéros de révisions permettant de retrouver facilement le code....c'est tout.

[DotNetMatt]

Apparement tu ne t'es pas suffisament renseigné Si tu utilises le serveur de builds, tu peux obtenir un livrable de la forme souhaitée. Pour cela il faut configurer la build. Ce qui est sûr c'est que l'output généré ne sera pas dans ton dossier Bin.

Si tu n'utilises pas le serveur de build alors effectivement tu peux regarder dans ton dossier Bin et obtenir ton exécutable. Encore une fois prends le temps de te documenter et de jouer avec les outils, puis reviens nous voir quand tu auras des questions plus précises. Rome ne s'est pas faite en un jour comme on dit

[BasicZX81]

Merci DotNetMatt, je me doutais bien que mes questions n’était pas assez précise mais c'est pas faute de chercher.....il faudrait juste que j'arrive à comprendre ce que je lis par moment .
Je voudrais refaire d'autres tests sur Visual Studio mais ça sera pas pour ce soir car il y a un soucis pour se connecter au serveur, ça marche 1 fois sur 10. J'espère juste que je n'est pas uploadé trop de code mais il me semblait qu'il n'y avait pas de limite à ce niveau là.....J'ai une belle page INTERNAL SERVER ERROR 500 sur mon portail web, Je réessaierais demain .

[DotNetMatt]

Non tu peux uploader autant de code que tu le souhaites (heureusement ). Aujourd'hui il y a eu un problème aux US impactant Visual Studio Online. Ca peut expliquer les erreurs 500... Tu peux suivre l'état des services via cette page : http://azure.microsoft.com/en-us/status/ Et si tu regardes dans l'onglet History, tu peux retrouver l'incident d'aujourd'hui.

[BasicZX81]

Bonsoir,
Bon, tout est rentré dans l'ordre. Je peux à nouveau me connecter.
J'ai procédé à des essais et j'ai enfin trouvé les fichiers livrables

Je pense avoir toutes les infos dont j'ai besoin pour me débrouiller sauf que j'aurais une dernière question :
J'ai vu que les définitions de Build se construisent à partir de "modèles" associés à chaque projets d'équipes. En l’occurrence j'utilise le Template par défaut (DefaultTemplate.11.1.xaml) qui contient, si je ne me trompe pas, tous les paramètres du processus de génération.
Hors j'ai l'intention de modifier le format du numéro de Build, est-ce une bonne idée d'enregistrer ces nouveaux paramètres dans un nouveau fichier Template et ce fichier peut t'il être réutilisé pour d'autres Projets d'équipe ?

Ça sera ma dernière question, promis

[DotNetMatt]

Hors j'ai l'intention de modifier le format du numéro de Build, est-ce une bonne idée d'enregistrer ces nouveaux paramètres dans un nouveau fichier Template et ce fichier peut t'il être réutilisé pour d'autres Projets d'équipe ?

Oui c'est l'objectif des templates de pouvoir être réutilisés sur X projets. Donc à priori pas de soucis, surtout si tu souhaites l'utiliser de partout sans exception. S'il y a des exceptions alors c'est à toi de voir ce qui est le plus judicieux selon si tu as plus d'exceptions ou plus de cas pouvant utiliser le template. Ce que tu peux aussi faire c'est sauvegarder le template original pour pouvoir l'utiliser plus tard, au cas où.

[BasicZX81]

Merci pour tout ces bons conseils DotNetMatt,
Franchement j'étais déjà venu sur cette partie du Forum, j'ai jamais été déçu....Pour les "petits" développeur comme moi (isolé et amateur) c'est important d'avoir des réponses quand on est bloqué,surtout que ce sont des réponses de qualités bien souvent, et sans ça je n’aurais jamais pu faire mes 2 gros programmes (27000 et 6000 lignes de code). Oui parce que je l'ai ai terminé fin 2013 en fait, je fait juste quelques retouche de temps en temps.
Je passe en résolu, je pense avoir tous les éléments pour m'en sortir, encore merci.