Bonjour,
je voudrais bien savoir comment je peux mettre des versions à chaque mise en place de modification sur un projet de telle façon que je puisse différencier les versions et comme ça je me trompe pas quand je travaille.
Merci
Version imprimable
Bonjour,
je voudrais bien savoir comment je peux mettre des versions à chaque mise en place de modification sur un projet de telle façon que je puisse différencier les versions et comme ça je me trompe pas quand je travaille.
Merci
Je te conseille d'utiliser un logiciel de versionning du style de Tortoise SVN.
Un exemple pour ton problème est qu'à chaque fois que tu voudras "figer" une version de ton projet, il te suffira de faire un "Commit" et tu auras accès à un log avec tous les fichiers modifiés/ajoutés/supprimés ainsi que les changements sur chaque (avec un WinMerge) que tu auras effectués entre 2 Commit, tu pourras également revenir à une version précédente ou annuler tes changements.
S'il s'agit de versions de l'assembly, cela passe par les attributs déclarés dans AssemblyInfo.cs
S'il s'agit effectivement de mettre en place une gestion des sources, il y a des pelletées de solution. Pour citer les plus courantes :
* Serveur SVN local avec TortoiseSVN (fichiers stockés sur ton disque dur)
* Serveur SVN distant. Voir OVH par exemple : moins de cent euros par an pour un serveur mutualisé avec ftp, svn, etc.
* Serveur Git via Github, gratuit si open source ou moins de cent euros par an pour leurs premières offres (un collaborateur, cinq dépôts).
La seconde nécessite tout de même de manipuler un serveur linux distant pour la mise en place. Vraiment rien de sorcier mais si tu es un parfait débutant et que tu ne sais pas ce que "ls", "vi" et "chmod" veulent dire, tu vas tout de même en baver. Les deux autres sont triviales.
A l'usage, les trois sont simples mêmes si ce genre d'outils nécessite une compréhension au moins rudimentaire de leur fonctionnement, l'apprentissage de quelques règles et de se défaire de certaines habitudes (renommage et déplacement des dossiers via Tortoise par exemple et non pas depuis ton IDE).
Enfin, SVN est encore très répandu mais perd clairement du terrain au profit de Git et autres qui sont plus souples dans le cadre d'un travail en groupe. SVN fera néanmoins parfaitement l'affaire pour un particulier mais si le but est d'acquérir des compétences, autant viser Git.
pour le gestionnaire de code source, tu as aussi TFS, mais la licence est très chère ! A moins que tu aies un compte msdn student qui te permet(ait ?) de le télécharger et de l'installer.
s'il s'agit effectivement de N° de version, tu as dans l'assembly info un N° de version et un N° de fichier.
Le premier impact le N° des dll dans le gac (si tu les y mets) et pas le second.
Bonjour,
Merci pour vos réponses, en fait ce que je cherchais s'était comme il a dis DonQuiche@ DonQuiche : ça sert à quoi de mettre les dll dans le gac ? et si je ne les met pas ca va générer quoi exactement comme problèmeCitation:
S'il s'agit de versions de l'assembly, cela passe par les attributs déclarés dans AssemblyInfo.cs
MerciCitation:
Le premier impact le N° des dll dans le gac (si tu les y mets)
Bonjour.
La raison fondamentale pour l'existence du GAC est de fournir un emplacement conventionnel, "standard", pour placer les biblios partagées. Le framework ira voir le GAC pour trouver les biblios que tu demandes.
Avant de poursuivre, deux précsions :
* Par défaut, les biblios ne sont pas référencées par leur chemin d'accès mais par leur nom complet (nom, version, signature éventuelle, etc). Le framework cherche donc une assembly correspondant à ce nom complet dans plusieurs répertoires (le GAC, celui de l'application, etc)
* Les assemblies doivent être signées pour être placées dans le GAC. Cette signature permet au framework de garantir que la dll demandée avec laquelle se lie une application est bien celle qu'elle voulait.
* Les assemblies placées dans le GAC bénéficient d'une pleine confiance : elles ont toutes les permissions. C'est la raison pour laquelle l'utilisateur doit approuver le placement d'une assembly dans le GAC.
Je crois que c'est la raison de la signature, non ?Citation:
Envoyé par DonQuiche
Pour tes dll dans le GAC, si tu changes le N° de version, ce n'est plus la même (logique) pour la raison donnée par DonQuiche. Il te faut donc recompiler les application appelant cette nouvelle version si tu veux l'utiliser. Notons, que plusieurs version d'une dll peuvent exister dans le gac et que deux application compilées en référençant 2 versions peuvent fonctionner.
Si tu veux gérer ton code au fur et à mesure, je te conseilles d'utiliser le N° de fichier en utilisant les 4 N°
Majeur.Mineur.Build.Revision.
Quand tu fais une release, tu utilises ce N° comme N° de version d'assembly. En cours de développement ton assembly est en retard, sur le N° de fichier, mais tu rattrapes avec la livraison. (surtout si tu gac)
Je dirais plutôt que non. D'abord parce qu'une assembly peut être signée sans pour autant être dans le gac et, dans ce cas, elle n'a pas la pleine confiance. Ensuite parce qu'on pourrait très bien garantir une pleine confiance aux assemblies dans le gac sans imposer une signature à partir du moment où le système d'exploitation demande une confirmation à l'utilisateur pour toute écriture dans le GAC.Citation:
Envoyé par kheironn
Les deux mécanismes sont donc indépendants. Le GAC assure la pleine confiance parce que l'utilisateur a validé ce choix, la signature assure que c'est bien la version que l'on veut et qu'elle n'a pas été modifiée par un tiers.
c'est ce que je voulais dire...Citation:
Envoyé par DonQuiche
Bonjour,
je viens de regarder à l'entour deet je viens de trouver ceci http://www.developpez.net/forums/d22...s-application/ j'espère que cela peut aider, c'est bien détaillé. Que pensez vous?Citation:
Si tu veux gérer ton code au fur et à mesure, je te conseilles d'utiliser le N° de fichier en utilisant les 4 N°
Majeur.Mineur.Build.Revision