Comment ASP.NET gère-t-il les déploiements?

Question

J'ai seulement pu lire que ASP.NET détecte les modifications apportées à des fichiers spécifiques comme les fichiers aspx, les DLL et autres. Il se redémarrera, terminera les demandes en cours et les nouvelles demandes avec les nouveaux fichiers déployés.

Mais que se passe-t-il dans le temps depuis le premier fichier copié jusqu'à ce que le dernier ait été échangé? Si j'échange le premier fichier DLL, alors une requête arrive mais les autres fichiers DLL sont dans une version plus ancienne - va-t-il tomber en panne? Est-ce que asp.net attendra quelques secondes et ne se relancera après X secondes de changements de fichier (pertinents)?

Thx!

Answer 1

Vous avez 4 questions ici: Que se passe-t-il dans le temps depuis le premier fichier copié jusqu'à ce que le dernier ait été échangé? - Il y a une heure fixe pendant laquelle .net attend de voir si d'autres fichiers ont été modifiés avant de démarrer le nouveau domaine de l'application avec la nouvelle DLL chargée.

Si j'échange le premier fichier DLL, alors une requête arrive mais les autres fichiers DLL sont dans une ancienne version - va-t-il se bloquer? - Cela dépend des changements de code dans la DLL. Si la nouvelle DLL fonctionne correctement avec l'ancien code, tout ira bien. Mais si le domaine de l'application fait tourner la nouvelle DLL et que cette nouvelle DLL dépend de quelque chose qui n'est pas encore là ... alors oui, il va lancer une exception.

Est-ce que asp.net attendra quelques secondes et ne se relancera après X secondes de changements de fichiers (pertinents)? - Oui. Je n'ai pas été capable de trouver combien de temps ce temps est. Mais dans mon expérience personnelle, c'est quelque part dans la gamme de 1-2 secondes.

J'ai aussi trouvé une bonne explication ici sur le domaine d'application et re-chargement de DLL: http://odetocode.com/Articles/305.aspx

Si vous copiez un dll mis à jour dans le bac d'une application sous-répertoire, le moteur d'exécution d'ASP.NET reconnaît là est nouveau code à exécuter. Depuis ASP.NET ne peut pas échanger la DLL dans l'AppDomain existant , il démarre un nouveau AppDomain. L'ancien domaine d'application est "vidange arrêté", c'est-à-dire que les demandes existantes sont autorisées à terminer l'exécution et une fois qu'elles sont toutes terminées, le AppDomain peut se décharger. Le nouveau AppDomain commence avec le nouveau code et commence à prendre toutes les nouvelles demandes.

Typiquement, quand une DLL charge dans un processus , le processus verrouille la DLL et vous ne pouvez pas écraser le fichier sur le disque. Toutefois, AppDomains dispose d'une fonctionnalité connue sous le nom de Cliché instantané qui permet aux ensembles de rester déverrouillés et remplaçables sur le disque.

L'exécution initialise ASP.NET avec cliché instantané activé pour le répertoire bin . L'AppDomain copiera toute DLL dont il a besoin à partir du répertoire bin à un emplacement temporaire avant de verrouiller et de charger la DLL dans la mémoire. Shadow Copy nous permet d'écraser toute dll dans le répertoire bin pendant une mise à jour sans prendre l'application web hors ligne.