Bonjour par ici
 
Aujourd'hui, j'ai une petite question sur laquelle je sèche, probablement de par l'aspect spécifique du truc...
Peut être que vous, la famille HFR, avez déjà été confronté à un cas comme ça ?
 
Je bosse au boulot sur une solution contenant une 40aine de projets, donc 5 applications web écrits dans des langages différents.
Habituellement, on livre ces applications un peu à l'arrache, via MS Deploy sur le serveur IIS de prod, après avoir fait des ZIP de backup des binaires actuels...
Suite à un crash serveur un peu violent, l'infra souhaite que nous mettions en place un versionning de nos binaires quand on les livre.
 
L'idée c'est que mes collègues à l'infra puissent récupérer un numéro de version pour chacun de mes projets, pour savoir s'ils doivent inclure le dossier de l'appli dans les backups quotidiens, ou pas.
Ils disposent de PowerShell pour les y aider, donc ils sont assez limités (lecture d'un fichier texte, retour d'exécution d'un petit .exe ....).
Ils ne peuvent *pas* exécuter de script SQL pour récupérer la version déployée en cours.
 
Je suis obligé d'utiliser les mécaniques natives à .NET parce que les projets sont tellement hétéroclites qu'il faudrait développer ou installer un truc différent pour chaque projet... c'est pas envisageable.
Je pensais donc m'appuyer sur les AssemblyInfo que, avec un petit évènement de post-build (ou plutôt, lors du publish de mes applis), j'irai stocker en contenu d'un fichier "version.txt" à la racine de chacune de mes appli.
 
Savez-vous comment mettre ça en place ?
Je ne sais pas comment je peux exécuter du code C#/VB.NET au moment de la publication de mon appli pour récupérer les infos de l'assembly et altérer un fichier texte
 
Merci d'avance pour votre aide

C'est pas aussi un petit peu leur job de backuper leur serveur quotidiennement avec des outils intelligents pour faire du backup différentiel ?  
Si un fichier a changé, on backupe, sinon on se repose sur le snapshot précédent.
Serveur backupé, binaire backupé aussi : simple.
 
Pour moi côté dév vous devez être capable de régénérer un build avec les sources d'un instant X et travailler sur une version précédente (branching pour patch, etc) mais pas vous occupez de savoir ce qu'il y a à restaurer sur les serveurs en cas de vautrage de l'infra, chacun son taf.
J'ai l'impression qu'il y a un glissement de la responsabilité là.
 
Mais sinon dans VS tu peux ajouter un Post Build Event qui fera tout ce que tu voudras, y compris appeler un EXE de ton cru qui générera dans le répertoire de publication les artefacts permettant de tracer les infos du build, genre dans ton fichier .txt avec ton numéro de version et l'instant où le build a été généré, etc.
Ca peut se faire aussi (un peu plus difficilement) après un Publish.  
 
Mais  
- Ca ne protège pas des rigolos qui vont mettre à jour des DLL directement en prod sans republier toute l'appli.
- Ca ne résoud pas le souci du backup des fichiers de conf qui sont parfois abominablement complexes.
- Cf début du post

Merci pour ta réponse TotalRecall.
 
Entre temps, j'ai discuté un peu avec les gars, et on est tombé sur la même conclusion que toi.
Moi, je suis capable de gérer la version des binaires que je leur livre (et donc de leur publier une version N grâce à l'historisation du contrôle de code source), mais je peux pas leur assurer que le fichier "version.txt" sera garant de la nécessite de faire un backup ou pas...
 
Exemple concret : pour une modification d'urgence dans mes web.config, ou pour un hotfix dans un fichier HTML/XML/ASP (oui, on en a encore...), et suivant la criticité évidemment, je vais aller modifier à chaud et ramener le fichier chez nous dans le TFS... En aucun cas je vais prendre le risque de faire une livraison complète, de plusieurs dizaines de minutes, en pleine journée... et donc mettre à jour le fichier "version.txt" ...
 
A mon avis, tout comme toi, je pense que se baser sur les attributs / date modif des fichiers est bien plus parlant

Perso chez mes clients j'installe toujours un repo GIT pour les dossiers de livraison.

Après, ils décident s'ils le synchronisent ou non avec un serveur.

Ca permet, en plus de la gestion du contrôle de sources de mon côté, de suivre les livraisons de binaires et/ou de configuration.
=> Possibilité de comparer le paramétrage d'une livraison à l'autre, de vérifier qu'une anomalie est apparue en PROD avant ou après telle livraison, de récupérer les binaires ou le paramétrage d'une version antérieure pour tester, etc.