Remplacer les fichiers .dll pendant l'exécution de l'application?

J'ai plusieurs serveurs de jeux qui utilisent un certain fichier .dll pour fonctionner. Parfois, je dois mettre à jour les serveurs de jeux, mais je ne veux pas interrompre les jeux déjà en cours d'exécution.

Existe-t-il un moyen de remplacer le fichier .dll (il est verrouillé par Windows) afin que les prochaines instances des serveurs de jeux qui utilisent ce fichier ouvrent la nouvelle version, et les anciennes continuent d'utiliser l'ancienne version de ce fichier .dll jusqu'à ce qu'elles soient redémarrées ?

Est-il sûr de simplement déverrouiller le fichier à l'aide de l'un de ces outils qui le font et de le remplacer?

En fait, vous pouvez et cela fonctionne généralement sans aucun problème (mais pas toujours)

Ce que vous faites, c'est renommer le fichier sans le déplacer et déplacer le nouveau fichier dessus. Cela gardera les descripteurs du fichier valides et fonctionnels afin que les instances préexistantes puissent toujours accéder correctement au fichier et que les nouvelles instances (ou les nouveaux descripteurs) accèdent au nouveau fichier.

De toute évidence, si un programme rouvre le même fichier dll et s'attend à ce qu'il reste exactement le même (par exemple, s'il y a des ressources à charger à partir de la dll et que les références à ces ressources sont extraites du code en cours d'exécution lorsque la dll est chargée ), cela posera problème, mais ce n'est certainement pas la norme.

Non. Même si une DLL peut être entièrement mappée dans la mémoire physique pendant l'exécution de l'application, il n'y a certainement aucune garantie à ce sujet. Des portions de DLL (et même d'exécutables) peuvent être mappées dans la RAM tandis que d'autres bits restent sur le disque et peuvent être lues ultérieurement.

Changer le fichier sur le disque alors que Windows en a des morceaux mappés dans la RAM ne se terminerait pas bien. Windows le verrouille pour une bonne raison.

Edit: Je dois clarifier quelque chose car certaines personnes semblent vouloir blâmer Windows pour ce qui est en fait un problème de conception d' application , pas un problème de conception de système d'exploitation.

Vous pouvez mettre à jour les DLL que les applications utilisent dans Windows sans terminer le processus, mais l'application doit avoir été écrite de manière à pouvoir signaler la décharge de l'assembly, attendre la fin de la mise à jour, puis recharger la DLL. Cela n'a rien à voir avec le système d'exploitation que vous utilisez. C'est un problème de conception d'application.

Modifier: Voir également la réponse de Stéphane pour une solution possible qui pourrait fonctionner, selon la façon dont votre application spécifique répond à son changement de DLL. Je pense qu'il mérite un vote positif.

Non, vous ne devez pas bricoler avec les descripteurs de fichiers existants.

Si vous pouvez prendre le contrôle du chargement de l'assemblage et spécifier qu'il est ouvert avec FileShare.Delete, il devrait être possible de le renommer. Les processus existants continueront de référencer l'assembly renommé.

/programming/7147577/programmatically-rename-open-file-on-windows .

Non, malheureusement ce n'est pas possible.

Désolé, pour être exact, sauf en cas de liaison tardive, ce qui signifie que l'application utilise cette DLL lorsqu'elle exécute une partie du code dans cette DLL, mais elle n'est toujours pas fiable.

Vous pouvez voir comment fonctionne le processus hébergé asp.net et développer quelque chose de similaire.

Il prend toute l'application Web et la déplace vers un emplacement temporaire à partir duquel l'application est réellement chargée. Ensuite, il laisse un processus pour surveiller les modifications dans le dossier d'origine, lorsqu'il est détecté, il crée une nouvelle instance de l'application dans un nouvel emplacement temporaire et commence à rediriger les nouvelles demandes vers cette application. L'ancienne application est ensuite supprimée une fois les demandes en attente terminées.

(Nitpicking, oui, c'est une vue simplifiée des choses, dans la plupart des cas, IIS met les demandes en file d'attente jusqu'à ce que la nouvelle application soit en mesure de prendre le relais)

Il y a une dizaine d'années, j'étais un utilisateur heureux de http://www.eggcentric.com/ISAPILoader.htm qui a fait l'échange de dll IIS ISAPI. M. Egg soutient toujours sa solution FOSS.

NSIS Installer a une option comme Déplacer vers la température au redémarrage de la machine, le système d'exploitation marque certains fichiers pour les déplacer vers un autre emplacement au prochain démarrage, au prochain démarrage de la machine, ces fichiers marqués se déplacent automatiquement vers le nouvel emplacement que vous avez sélectionné précédemment. Une petite recherche à ce sujet vous fera plaisir à cet égard.