J'ai été un peu cruel ce week-end et j'ai décidé de mettre à niveau le projet vers la plate-forme 2.0. Comme VS2003 et 2005 peuvent coexister, le problème est relativement simple à résoudre. Installez la version Pro de 2005, ouvrez le projet d'origine et effectuez la mise à niveau. L'assistant apparaîtra automatiquement. Le projet contient 7 sous-projets. Toute la logique et l'affichage sont implémentés dans le projet d'arrière-plan. Chaque fichier du projet Web frontal implémente uniquement un appel à la méthode d'arrière-plan, et aucune méthode avancée n'est utilisée dans la syntaxe d'arrière-plan. la mise à niveau est très fluide.
Pour résumer, les fichiers de projet du projet Web ont été supprimés. Il s'avère que deux fichiers ASPX sans rapport ont également été pris en compte dans le processus de compilation. Je l'ai compilé, téléchargé sur le serveur et signalé une erreur. Plus tard, j'ai découvert que le projet nouvellement compilé ne contenait pas la DLL du projet Web, mais qu'elle était toujours présente dans le répertoire du serveur. Le résultat est un désordre de références internes. Supprimez la Dll de l'ancien projet Web et c'est OK.
Ensuite, j'ai prévu d'essayer le mode de publication. J'ai utilisé la fonction de publication du site Web dans l'élément de menu Générer de VS2005 pour définir le répertoire dans lequel publier. L'option était définie pour ne pas autoriser les mises à jour, donc le répertoire Web était copié. le processus de compilation était très compliqué. Une fois la compilation terminée, un tas d'éléments ont été générés dans le répertoire bin. Je pensais que copier ces éléments sur le serveur éliminerait le besoin d'une compilation propre. Il s'avère que le processus csc apparaît toujours lors du premier accès à la page. Après le basculement de l'ensemble du site Web, il restait encore un certain nombre de processus csc, mais le processus de compilation était un peu plus rapide qu'avant.
Un autre problème grave s'est produit. Le programme a semblé redémarrer automatiquement après un certain temps, provoquant sa nouvelle compilation. Plus tard, une fenêtre d'erreur est apparue sur le serveur, indiquant qu'il y avait une erreur dans le processus w3wp.exe. il? Après avoir sélectionné Annuler, w3wp.exe a automatiquement redémarré et une nouvelle série de recompilation a commencé. Ce processus s'est produit trois fois et j'avais tellement peur que je suis rapidement revenu à la version 1.1. J'ai jeté un œil dans l'observateur d'événements et j'ai trouvé un tas d'exceptions non gérées, qui étaient essentiellement des erreurs avec des valeurs vides. C'est étrange, il n'y a eu aucun problème dans la 1.1, et le code n'a pas été modifié.
Plus tard, j'ai trouvé un article (personne en chinois ne semble l'avoir mentionné), http://www.eggheadcafe.com/articles/20060305.asp . La gestion des exceptions non gérées dans la version 2.0 est très différente de celle de la version 1.1. différent, 1.1 l'ignorera à moins qu'il n'affecte la génération de pages. Et 2.0 amènera le processus à signaler une erreur, affectant directement le fonctionnement de l’ensemble du site Web. Cela ressemble à un problème sérieux, mais cela semble plus raisonnable, sinon les programmeurs continueront à ignorer cette erreur. Cependant, en raison de ce problème, l’impossibilité de changer de site Web constitue également un problème sérieux. Une méthode de transition en douceur est donc toujours nécessaire. Comme mentionné ci-dessus, cette méthode consiste à écrire vous-même un HttpModule pour gérer toutes les exceptions non gérées et enregistrer les informations sur les exceptions dans les événements système, ce qui est avantageux pour les programmeurs pour le traitement. Et le téléchargement du code source et du fichier binaire de ce HttpModule est également fourni ci-dessus, y compris la WebApp de démonstration.
Aujourd'hui, j'ai enfin compris la méthode de compilation de la version de pré-déploiement 2.0. Il est erroné d'utiliser VS pour publier le site Web. Vous devez utiliser aspnet_compiler.exe pour compiler manuellement, et son processus de compilation est basé sur les paramètres réels du site Web. En d'autres termes, vous devez télécharger le contenu du projet Web sur le site Web, définir le chemin du site Web dans IIS, puis utiliser aspnet_compile pour compiler. Ce processus place en fait la DLL générée dans C: The. ceux du répertoire de cache dans WindowsMicrosoft.Net sont exactement les mêmes que ceux générés par csc.exe lorsque l'utilisateur accède réellement à la page. Après cette étape, aucune action de compilation ne se produira lorsque l'utilisateur visitera deux fois.
Tellement fatigué. À propos, j'ai pensé à une méthode de commutation transparente, en gardant deux sites Web pointant vers deux répertoires différents, dont l'un n'a pas d'en-tête d'hôte et l'autre a un en-tête d'hôte pour la mise à jour. Après avoir mis à jour le site Web avec l'en-tête d'hôte, utilisez aspnet_compiler pour le compiler, puis changez les en-têtes d'hôte des deux sites Web, afin que les utilisateurs nouvellement visités soient dirigés vers le site Web nouvellement compilé et que l'utilisateur ne ressente aucun retard. Mettez simplement à jour un autre site la prochaine fois.
http://www.cnblogs.com/unfish/archive/2006/09/10/500230.html