Gestion des MAJ d'une application partagée

Bonjour à tous,

Un petit souci me gêne depuis un moment et je me dis "si ça se trouve, il y a une méthode propre pour gérer ça"... google n'est pas d'accord, je me tourne vers vous ;-).

J'ai une application C# Winform sur un serveur. Les utilisateurs y accèdent via RemoteApps. Tout va bien.
Le souci c'est que lorsque j'ai une mise à jour à faire, il faut que tous les utilisateurs ferment l'application pour me permettre d'écraser les fichiers!
Vous connaissez le truc : on le demande, et le temps que le dernier ferme le 1er a déjà ré-ouvert... je finis toujours pas forcer l'arrêt des processus mais il peut y avoir perte de données (l'appli sauve la session lors des fermetures normales).
Pas idéal.

Côté solution, j'envisage un truc du genre "l'appli regarde une variable sur le serveur : si elle est non vide, cela programme l'arrêt à l'heure indiquée".
Ca devrait marcher, mais j'entends déjà les utilisateurs se plaindre...
Y a-t-il une meilleure méthode, une "règle de l'art", "best practice" pour ce cas de figure? Une méthode qui par exemple permet de laisser les utilisateurs avec leur session en mettant les fichiers "en mémoire" pour me permettre d'écraser le fichier source (et lorsque l'utilisateur se reconnectera, il aura la nouvelle version)? Peut-être utopique, mais au moins je MAJ et les utilisateurs travaillent sans coupure, tout le monde est heureux ;-).

Merci pour vos retours!

je suis pas expert de remoteapps, mais la technique du launcher devrait fonctionner

à savoir l'utilisateur lance le launcher, qui lui regarde les sous dossiers pour trouver la plus récente version et lance l'exe de celle ci

un service en tache de fond (ou une copie à la main) permet de vérifier s'il faut une mise à jour auquel cas ca créé un nouveau sous dossier avec la version

soit le launcher est encore en route et s'occupe de vérifier, soit l'exe vérifie lui même s'il y a plus récent, auquel cas tu peux demander à l'utilisateur de basculer sur la nouvelle version

à peaufiner mais si remoteapps permet à un exe d'en lancer un autre je pense que ca peut convenir
(après remoteapp je ne suis pas sur que ca apporte grand chose, ca doit décaler le problème ...)

Merci, c'est effectivement une idée à creuser.
Pour mon app, le chemin d'exécution est utilisé pour des fichiers annexes (log, sauvegarde session,...) et le chemin appelé n'est pas toujours le chemin relatif... (et de ce que j'ai déjà vu du code, pas toujours de la même façon, ce serait trop simple).
Mais à voir ce que je peux en faire, merci pour l'idée :)

Pas d'autres retours ou suggestions? Ne me dites pas que vous faites tous les MAJ applicatives au milieu de la nuit :-D (oui, c'est aussi une solution :aie:)

je pense que le plus courant est d'avoir l'appli sur chaque poste, donc les mises à jours ne posent pas spécialement de problème

AYE \o/

Oui, le problème était toujours d'actualité, et à chaque MAJ je me penche à nouveau dessus car ce process "pas propre" m'énerve. Et limite le nombre de MAJ possible.
Et là... miracle, j'ai trouvé et c'est tout con en plus!

Rappel du problème : mon appli (installation unique en RemoteApp) est exécuté par plusieurs utilisateurs, et Windows verrouille donc le(s) fichier(s).
Lors d'une MAJ, je ne peux les remplacer, il faut forcer la fermeture des instances (protestation des utilisateurs, risque de perte de données, temps perdu à prévenir et re-prévenir et couper les retardataires...)

Solution : En fait, quand Windows verrouille un fichier, il est impossible de le supprimer (donc indirectement de l'écraser par un nouveau). Par contre, il est possible de le renommer sans stopper les instances en cours.
... à partir de là, la solution s'impose : lors d'une MAJ, on renomme les anciens fichiers et on copie à la place les nouveaux.
Les instances en cours continuent normalement.
Lors des lancements suivant, c'est la nouvelle version qui se lance.
Tout le monde est heureux, le monde est plus beau, etc :mrgreen:.
Reste juste à vérifier qu'il n'y a réellement aucun impact...

Dans mon cas, dans un premier temps, un simple batch fera le job. Comme quoi, parfois la solution est plus simple qu'on imagine.
Si ce post peut servir à d'autre, j'en serais heureux ;).