Sébastien Bovo [Microsoft France] : ASP.NET

Debogage .NET 4.0

Sebastien Bovo — Mon, 30 Nov 2009 20:32:00 GMT

Visual Studio 2010 et le .NET Framework 4 sont disponible en Beta 2 depuis quelques semaines. Afin de vérifier un comportement qui m’a un peu surpris, je vais les utiliser pour le débogage.

Voici le contexte : Dans un précédent billet, je parlais du deployment retail="true" pour ASP.NET en faisant référence au billet de Scott Guthrie. Je pensais que retail=true était la solution pour s’affranchir du debug=true dans tous les Web.config du serveur. C’est seulement en parti vrai car le timeout des pages ASP.NET n’est pas modifié et reste démesuré si vous avez debug=true dans votre Web.config.

Voici la preuve…

Page d’exemple

J’utilise un page exemple qui ne se termine jamais. Dans la vrai vie, nous aurons une boucle infinie plus complexes ou un bloclage quelconque. Dans tous les cas, le débogage est identique. Mon but est d’obtenir le timeout des pages ASP.NET.

<%@ Page Language="C#" %>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

    protected void Page_Load(object sender, EventArgs e)
    {
        DateTime t1 = DateTime.Now;
        while (true)
        {
            DateTime t2 = DateTime.Now;
        }
    }
</script>

Clin d’œil à Visual Studio 2010 et l’utilisation du zoom (CTRL+mollette de la souris) :

Cette page doit être positionnée dans un site Web utilisant un pool d’application configuré avec le Framework 4.0.

Avant de lancer WinDbg, naviguons vers notre page de test.

Lancement de WinDbg, chargement des symboles et SOS

Veillez bien à lancer Windbg en tant qu’administrateur et attachez-vous au processus W3WP.EXE en cours d’exécution (F6) :

Chargement des symboles publics :

.sympath SRV*c:\symbols*http://msdl.microsoft.com/download/symbols/

Chargement de SOS livré avec le .NET Framework 4.0 :

.load C:\Windows\Microsoft.NET\Framework\v4.0.21006\SOS

Affichage des objets

Maintenant, cherchons notre page en court d’exécution

!DumpHeap -type System.Web.HttpContext

!do 062d9d18

Comme il s’agit d’un objet de type TimeSpan, nous devons utiliser la méthode !DumpVC (Pour information, voici le pointeur MSDN vers SOS - http://msdn.microsoft.com/en-us/library/bb190764.aspx)

!DumpVC 532747bc 062d9dd0

La valeur du timeout donnée est un nombre de ticks CPU. Sachant qu’il y a 10000 ticks par millisecondes. Pour obtenir le temps en secondes, nous devons donc diviser la valeur par 10000 puis par 1000. Utilisons Windbg comme calculatrice :

?1100000000/10000/1000

Le timeout de la page ASPX est de 110 secondes.

Nous avons bien le comportement normal et celui par défaut décrit dans le fichier "Web.config.comments" :

Maintenant, regardons avec exactement la même démarche, ce que nous avons avec debug=true (dans Web.config) et retail=true (dans le Machine.config) :

Je vous passe toutes les copies d’écran, voici juste les deux dernières commandes :

Le timeout est de 30 000 000 secondes soit 347 jours. Effectivement, dans ce cas, nous avons tout le temps de déboguer nos pages… Et le retail=true n’a pas changé ce comportement.

La conclusion est : vérifiez que vous n’avez pas debug=true dans tous les Web.config en production même si vous avez retail=true.

Plutôt intéressant :-) Qu’en pensez-vous ?

Sebastien.

Plan d‘action pour la capture des informations lors d’un problème de production IIS

Sebastien Bovo — Wed, 13 May 2009 17:38:00 GMT

Je fais suite à mon précédent billet sur l’introduction sur le débogage en production afin de vous donner plus de précisions sur la collecte d’informations lors de l’apparition d’un problème en production.

Dans tous les cas se présentant à vous, je vous conseille de récupérer des serveurs Web les logs IIS, les logs HTTPErr et vos logs applicatifs. Vous trouverez les explications dans le billet Données à récolter pour un travail de surveillance ou d'investigation sur un serveur Web. Ces logs nous permettent de vérifier la charge utilisateur, les temps de réponses, les erreurs HTTP : ce sont des informations précieuses à relier avec le comportement observé de l’application. Aussi, si vous avez la possibilité de prendre un log Perfmon, cela constitue un apport d’informations supplémentaires.

D’un point de vue système, je résumerais les problématiques de production en deux comportements distincts :

Hang = Etat de blocage "deadlock" (avec ou sans 100% CPU) ou d’attente "hang" du processus
Crash = Arrêt "crash" du processus

La prise de dumps peut se faire par le script Adplus. Voici comment faire : Procédures de prises de dumps pour un serveur Web

D’une manière générale, vous pouvez utiliser Adplus pour les prises de dumps/logs pour tous les processus et pas pour IIS seulement. Les paramètres les plus utiles sont :

-p	–>	Spécifie le PID du processus
-pn	–>	Donne le nom du processus (plutôt que son PID)
-o	–>	Renseigne le répertoire de sortie pour la création du dumps

Ainsi, pour une prise de dumps de plusieurs processus et la création des dumps dans un répertoire particulier, la commande ressemble à

cscript.exe adplus.vbs -pn w3wp.exe -pn inetinfo.exe -crash -o c:\temp -quiet

Deux autres paramètres sont utiles :

-NoDumpOnFirst	–>	Permet de ne pas surcharger le débogueur (et donc le serveur) qui prend un mini dump pour chaque exception de première chance. Logue toutes les exceptions levées
-NoDumpOnSecond	–>	Aucune prise de dump mais seulement le remplissage d’un log permettant de visualiser toutes les exceptions levées

Pour vous donner plus de précisions, en deux mots, il existe deux types d'exceptions : première chance et seconde chance.

Une exception de première chance peut être interceptée par votre application par un try/catch ou un gestionnaire d’exceptions global
Si cette exception n’est pas gérée, elle est à nouveau levée mais comme une exception de seconde chance. Dans ce cas, seul un débogueur peut l’intercepter et si aucun débogueur n’est attaché, l’application se ferme (autrement dit : le processus crashe).

Par exemple, pour une prise d’un dump lors du crash de l’application "WpfApplication1.exe", vous pouvez utiliser "cscript.exe adplus.vbs -crash -pn WpfApplication1.exe -o c:\temp -quiet".

Cette commande a pour effet de brancher le débogueur "cdb.exe" au processus WpfApplication1.exe. Le debogueur logue toutes les exceptions dans un fichier pendant l’exécution du processus et si une exception de seconde chance est levée (provoquant l’arrêt du processus), un dump est pris.

Le répertoire de sortie contient les fichiers suivants :

Process_List.txt - Liste des processus s’éxécutant sur la machine au moment du lancement de la commande
un ou plusieurs fichiers du type PID-2852__WPFAPPLICATION1.EXE__Date_05-13-2009__Time_15-46-0303.log - Log des exceptions levées par l’application
un ou plusieurs fichiers du type PID-2852__WPFAPPLICATION1.EXE__2nd_chance_NET_CLR__full_0a70_2009-05-13_15-46-10-421_0b24.dmp - Dump du processus

A noter que le répertoire et les fichiers contiennent la date et l’heure exacte de la prise de dumps. Dans l’exemple précédent, il s’agit du 2009-05-13 pour le 13 mai et 15-46-10 pour 15h46m.

Nous avons donc maintenant toutes les données nécessaires (en particulier les dumps) pour déboguer à tête reposée. Ouvrons le dump avec Windbg :-)

Sebastien.

>>> Suite : Premiers pas avec WinDbg

Gestion des versions des assemblies du GAC par ASP.NET

Sebastien Bovo — Thu, 30 Apr 2009 09:36:00 GMT

Le GAC nous permet de partager des assemblies entre plusieurs applications ASP.NET. La gestion des versions des ces assemblies en est aussi facilitée à condition de bien comprendre la différence entre Assembly version et File version.

Allez hop... Petite explication !

Lors de la mise à jour d’une assembly nous avons le choix entre changer l’Assembly version et la File version

Pour illustrer les deux possibilités, prenons l’exemple de plusieurs sites Web utilisant une même assembly dans le GAC (Assembly V1.0.0.0 / File V1.0.0.0). Les Web.config des applications ASP.NET utilisent :

Possibilité 1 : Modification mineure = Correctif

Nous mettons à jour cette assembly dans la GAC en gardant la même Assembly version mais en changeant la File version (Assembly V1.0.0.0 / File V1.1.0.0)

Dans la GAC, nous avons maintenant seulement la nouvelle assembly (Assembly V1.0.0.0 / File V1.1.0.0). Cette nouvelle assembly remplace la précédente car nous avons la même Assembly version. En effet, dans la GAC, deux assemblies du même nom ne peuvent pas avoir la même Assembly version
Les applications en cours d’exécution utilisent toujours la version précédente (Assembly V1.0.0.0 / File V1.0.0.0) car pour elles rien ne leur indique un changement (le web.config n’a pas changé)
Si l’appDomain redémarre : c'est-à-dire si l’application Web redémarre suite à une modification du Web.config par exemple, la nouvelle version n’est toujours pas chargée car l’ancienne est en mémoire dans le processus W3WP.EXE qui n’a pas redémarré
Si le processus W3WP.EXE redémarre suite à un recyclage, un crash, alors la CLR va chercher dans le GAC la dll et prend la nouvelle version

Possibilité 2 : Modification majeure = Nouvelle version

Nous mettons à jour cette assembly dans la GAC en changeant le numéro de l’Assembly version (Assembly V2.0.0.0)

Dans la GAC, nous voyons maintenant les deux assemblies

Les applications en cours d’exécution utiliseront toujours l’Assembly version 1.0.0.0 tant que le web.config n’est pas modifié pour mentionner le changement de version :

Comme modifions le Web.config, l’appDomain redémarre (sans redémarrage du processus W3WP.EXE) et prend en charge la nouvelle version

Conclusion en images :-)

Changement File version
Redémarrage W3WP.EXE	Prise en compte de la nouvelle version
Modification Web.config	Aucun changement

Changement Assembly version
Redémarrage W3WP.EXE	Aucun changement
Modification Web.config	Prise en compte de la nouvelle version

J’espère que ces éclaircissements vous aideront dans vos déploiements en production. A bientôt,

Sebastien.

Utilisez TinyGet pour effectuer rapidement une charge simple sur un serveur Web

Sebastien Bovo — Fri, 10 Apr 2009 12:04:00 GMT

L’outil TinyGet n’a pas vocation remplacer un outil de test de charge blogs.mais il s’avère extrêmement pratique dans certains cas : Je vous conseille de le garder dans vos outils favoris. Il vous permettra de simuler une charge basique sur une application Web en quelques lignes de commandes.

Les avantages sont les suivants :

Support du multithread pour effectuer des requêtes simultanées
Support des itérations
Paramétrage possible pour le type authentification, la version HTTP, les headers, le contenu de la requête, l’utilisation d’un certificat client
Attente d’un contenu particulier pour la réponse, le code de retour

Exemple de trois threads simultanés effectuant dix requêtes chacun

tinyget.exe -srv:sbovo02 -uri:/default.aspx -status:200 -threads:3 -loop:10

-threads donne le nombre de threads lancés simultanément.

-loop indique le nombre d’itérations

-status représente le code de retour attendu. Si TinyGet n’obtient pas ce code, un message est affiché dans la console

Exemple d’une requête attendant un contenu particulier

tinyget.exe -srv:sbovo02 -uri:/contenu.aspx -testContainString:"Texte"

-testContainString permet de mentionner quelle chaine (contenu dans le body de la réponse) nous attendons

Exemple d’une requête avec l’affichage de la trace TinyGet ou les headers de la réponse

tinyget.exe -srv:sbovo02 -uri:/stylesheet.css -trace

tinyget.exe -srv:sbovo02 -uri:/stylesheet.css -headers

Pour télécharger l’outil et l’aide associée : IIS 6.0 Resource Kit Tools - http://www.iis.net/downloads/default.aspx?tabid=34&g=6&i=1352

Je pense que vous avez bien vu l’utilité de cet outil soit pour simuler une charge soit pour vérifier les réponses d’une application Web.

Bonne utilisation !

Sebastien.

Paramétrages initiaux des pools d'applications IIS6

Sebastien Bovo — Tue, 02 Dec 2008 14:53:00 GMT

Voici quelques recommandations/explications qui pourront vous aider lors du paramétrage initial (manuel ou automatisé) de vos pools d'applications ASP.NET sur vos serveurs IIS6.

Pool d'applications et worker process

Un pool d’application correspond à un processus W3WP.EXE (ou plusieurs, si WebGarden est différent de 1). Il est possible de n’avoir qu’une seule version du .NET Framework chargée dans un processus.

Dans le cas où vous auriez plusieurs applications ou plusieurs sites Web,

Vous devez faire attention à ce que les sites Web/répertoires virtuels qui sont affectés à un pool d’applications, utilisent la même version du .NET Framework
De plus, afin de faire une séparation des applications en plusieurs pools d’applications, vous devez tenir compte :
- De la mémoire physique totale du serveur. En effet, chaque processus peut utiliser jusqu'à 1Go-1,5Go de mémoire virtuelle (rarement plus à cause de la fragmentation mémoire même si la limite théorique est de 2Go)
- Du nombre d’applications et de leur empreinte mémoire respectives
Des résultats des tests de charge. En effet, si d’après les tests vous vous apercevez qu’une application consomme beaucoup de mémoire ou crashe régulièrement, cela fait sens de l’isoler dans un pool d’applications afin d’investiguer

Paramètres des pools d'applications

Premier point : il est conseillé d’enlever l’option « Recycle worker processes (in minutes) ». En effet, ce paramètre n’est pas adapté à la production dans la mesure où le recyclage peut se faire à n’importe quel moment de la journée.

Par contre, si vous le jugez utile, vous pouvez planifier un recyclage journalier pendant un une plage horaire où l’application n’est pas utilisée. Cela permet de relancer un nouveau processus W3WP.EXE et de repartir à zéro concernant la charge mémoire. Par contre, lors de la première connexion du premier utilisateur de la journée, l’application se chargera dans le W3WP.EXE. Ce chargement sera sensible au niveau des performances. Il est possible de ne pas subir cette baisse de performances au démarrage de l’application en simulant plusieurs accès au site Web (par un outil, par script) avant que le premier utilisateur se connecte. Je vous conseille aussi d'utiliser la précompilation ASP.NET.

Si une application possède une fuite mémoire, vous pouvez l’isoler dans un pool d’applications. Il est possible d’utiliser les options de « Memory recycling » ou un recyclage planifié toutes les nuits. Sachez que lorsqu’il y a un recyclage et que si l’application utilise le mode de session dit « InProc » (dans le Web.config), vous perdez les variables de l'application et de sessions.

Le recyclage par seuil de mémoire peut se faire en fonction de :

- « Maximum used memory » ce qui correspond à la taille réelle du processus en mémoire

- « Maximum virtual memory » ce qui correspond à la taille de la mémoire virtuelle adressée par le processus

Le champ « Idle timeout » donne le nombre de minutes, après le dernier accès à l’application, au bout duquel le W3WP.EXE se décharge de la mémoire. Le but est d’économiser les ressources du serveur lorsque celui-ci n’est pas utilisé.

Le champ « Request queue limit » correspond à la taille de la file d’attente kernel utilisée pour les requêtes http entrantes destinées aux applications exécutées dans le pool d’applications.

Le champ « Enable pinging » indique le nombre de secondes entre chaque vérification de présence/bon fonctionnement du W3WP.EXE. Dans le cas où le processus ne répond pas, IIS en redémarre un nouveau afin de garantir la disponibilité du serveur Web.

Le champ « Enable rapid-fail protection » est le mécanisme inverse : si l’application est dangereuse pour la santé du serveur, le pool d’application est désactivé. Une action de l’administrateur est nécessaire pour le réactiver.

« Startup time limit » et « Shutdown time limit » correspondent au temps maximum que nous donnons à IIS pour, respectivement, démarrer/arrêter le W3WP.EXE. Si le processus ne démarre pas ou ne s’arrête pas dans le temps imparti. IIS fait un nouvel essai de démarrage/arrêt avec un nouveau processus.

Données à récolter pour un travail de surveillance ou d'investigation sur un serveur Web

Sebastien Bovo — Wed, 26 Nov 2008 10:35:00 GMT

Afin de commencer un travail d’investigation sur le fonctionnement d’une application Web (erreurs, crashes, performance, fuites mémoire), les données les intéressantes à récupérer d’un serveur Web sont :

- Logs IIS

- Logs HTTPERR

- Journaux d’événements

- Logs perfmon si possible

- Dumps si necessaire

Voici plus de précisions :

Logs IIS

Les logs IIS sont les fichiers contenus dans « C:\windows\system32\logfiles\W3SVCxxxx ». xxxx représente le numéro du site Web.

Vous avez ensuite un ou plusieurs fichiers portant la date du jour

Référence pour les codes IIS :

Description of Microsoft Internet Information Services (IIS) 5.0 and 6.0 status codes - http://support.microsoft.com/kb/318380/en-us

Logs HTTPERR

Il s'agit des logs de la partie Kernel de Windows qui réceptionne les requêtes et envoie les réponses.

Pour analyser les messages d'erreurs contenus dans ces logs :

Error logging in HTTP API - http://support.microsoft.com/kb/820729/en-us

Les journaux d’évènements Application, Système et Sécurité

Les journaux donnent des informations pertinentes sur les redemarrages d'IIS/des pools d'applications, sur erreurs remontés par les pools d'applications, etc...

WWW Service Events (IIS 6.0) - http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/ea584d51-16b5-4be7-9e70-7c7487ca4500.mspx?mfr=true
WWW Service Worker Process Events (IIS 6.0) - http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/ea584d51-16b5-4be7-9e70-7c7487ca4500.mspx?mfr=true

Deux précisions sur les logs IIS :

- Pour apprécier le temps total de traitement des requêtes par le serveur Web, nous vous conseillons d’activer le champ « time-taken » des logs IIS6. Ce champs donne le temps total de traitement de chaque requête à partir du moment où le serveur reçoit la requête jusqu’au moment où il renvoie la réponse HTTP. Cela englobe le temps de traitement Web Service et/ou Base de données sous-jacent.

- Le Win32 Status peut être aussi très utile. Il est possible d’en connaitre la signification avec l’outil « Err.exe » : Microsoft Exchange Server Error Code Look-up - Err.exe

Procédures de prises de dumps pour un serveur Web

Sebastien Bovo — Tue, 25 Nov 2008 10:50:00 GMT

Voici une procédure simple pour effectuer une prise de dumps sur IIS.

Utilisation d’ADPLUS.VBS

L’outil de prise de dumps est "adplus". Il est fourni avec les outils de débogage Windows téléchargeables à l’adresse - http://www.microsoft.com/whdc/devtools/debugging/.

La démarche d’installation que je vous conseille est la suivante :

- Télécharger les outils de débogage

- Faire l’installation sur une machine quelconque

- Copier sur le serveur Web le répertoire qui a été installé par les outils de débogage (par exemple dans « C:\debuggers\ »)

Prise d’un dump automatiquement lors d’un crash

Ouvrir une session avec un compte administrateur sur le serveur Web (se connecter avec « /console » si vous utilisez Terminal Serveur)
En ligne de commande, naviguer vers le répertoire contenant les outils de débogage
Lancer la commande suivante : « cscript.exe adplus.vbs -iis -crash -quiet ». A partir de ce moment, un débogueur est branché sur les processus IIS et prend un dump si un crash apparait
Récupérer le répertoire nommée de la façon suivante « Crash_Mode__Date_01-11-2007__Time_18-31-1515 »

Si vous avez beaucoup de mini-dumps, vous pouvez utiliser « cscript.exe adplus.vbs -iis -crash –quiet -nodumponfirst » pour avoir seulement un dump de second chance.

Prise d’un dump au moment du lancement de la commande

Pour une prise d’un dump immédiatement, dans le cas ou vous vous apercevez d’un problème ponctuel (application ne répondant pas, ayant de très mauvaises performances) ou dans le cas d’une fuite mémoire, la commande est « cscript.exe adplus.vbs -iis -hang -quiet » :

Ouvrir une session avec un compte administrateur sur le serveur Web (se connecter avec « /console » si vous utilisez Terminal Serveur)
En ligne de commande, naviguer vers le répertoire contenant les outils de débogage
Lancer la commande suivante : « cscript.exe adplus.vbs -iis -hang -quiet ». Les dumps des processus IIS sont pris immédiatement
Récupérer le répertoire nommée de la façon suivante « Hang_Mode__Date_01-11-2007__Time_18-31-1515 »

L’analyse des dumps se fait avec l’outil WinDbg (fourni avec les outils de débogage Windows) par vous et/ou par le support Microsoft.

Performances de vos applications ASP.NET - Quels compteurs étudier ?

Sebastien Bovo — Fri, 31 Oct 2008 15:15:42 GMT

Les compteurs de performance sont très nombreux et l’on peut rapidement s’y perdre ou perdre son temps à tous vouloir les utiliser. Pour être le plus productif possible, je vous propose par expérience, une liste de compteurs. Vous pouvez les étudier en tout premier lieu lors de vos tests de charges. Ensuite, en fonction des résultats, vous jugerez utile d’en ajouter d’autres plus ciblés.

Voici donc une liste qui peut vous servir de point de départ :

.NET CLR Exceptions
- # of Exceps Thrown/sec <<W3WP.EXE>>
.NET CLR Memory
- # Bytes in all Heaps <<W3WP.EXE>>
- % Time in GC
- Large Object Heap size <<W3WP.EXE>>
ASP.NET V2
- Requests Current
- Worker Process Restarts
ASP.NET Apps V2
- Errors Total/sec
- Request Execution Time
- Requests/sec
Processor
- % Processsor Time _Total
Process
- % Processsor Time <<W3WP.EXE>>
- Virtual Bytes <<W3WP.EXE>>
- Private Bytes <<W3WP.EXE>>
Web Service
- Anonymous Users/sec <<NomSiteWeb>>
- Get Requests/sec <<NomSiteWeb>>
- Post Requests/sec <<NomSiteWeb>>

Pour référence, je vous conseille les deux chapitres du guide "Improving .NET Application Performance and Scalability"

Chapter 15 — Measuring .NET Application Performance - http://msdn.microsoft.com/en-us/library/ms998579.aspx
Chapter 17 — Tuning .NET Application Performance - http://msdn.microsoft.com/en-us/library/ms998583.aspx

Aussi, voici un point d'entrée tres interessant sur les meilleures pratiques et l'optimisation des performances

Performance Overview - http://msdn.microsoft.com/en-us/library/cc668225.aspx

Par exemple, pour l'analyse des courbes obtenues, si vous regardez l’utilisation mémoire, l’important est de surveiller avant tout les compteurs "Process - Virtual Bytes <<W3WP.EXE>>" et "Process - Private Bytes <<W3WP.EXE>>" :

Les "Virtual Bytes" d’un processus correspondent à la mémoire réservée par ce processus. Elle est de deux types : "Reserved" et "Committed". Dans le premier cas, la mémoire n'est plus libre mais pas encore utilisée : le processus se réserve le droit d'y placer des données. La mémoire "Committed" est allouée et utilisée : elle est pris sur la mémoire physique du serveur.
Les "Private Bytes" d'un processus représentent la mémoire réellement utilisée et prise sur la mémoire physique. Autrement dit : il s'agit la partie "Committed" des "Virtual Bytes"

Par conséquent, si un de ces deux compteurs est en constante augmentation sans jamais redescendre, vous avez une fuite mémoire. Dans ce cas, d'autres compteurs pourront vous aider. Par exemple :

".NET CLR Memory - # Bytes in all Heaps <<W3WP.EXE>>" donne la taille mémoire utilisée par tous les objets .NET contenus dans le processus W3WP.EXE sélectionné. Si ce compteur augmente aussi de la même manière, la fuite mémoire est provoquée par les objets managés utilisés
"Large Object Heap size <<W3WP.EXE>>" comprend seulement les objets .NET dits volumineux (supérieurs à 85 ko). La mémoire utilisée par ces objets est particulière parce qu'elle n'est pas compactée/optimisée lors du passage du garbage collector. Son utilisation intensive peut provoquer de la fragmentation mémoire

Bon tests ou surveillances de vos applications ASP.NET :-)

A bientôt,

Sebastien.

Comment aborder la migration ASP.NET 1.1 vers 2.0

Sebastien Bovo — Thu, 22 May 2008 15:50:00 GMT

Visual Studio 2008 (et 2005) inclus un assistant de migration des projets ASP.NET. Cet assistant peut être utilisé de deux façon :

Migration vers le mode de projet "Web Application Project". Ce type de projet est similaire à celui que l’on connait en Visual Studio 2003 et est conseillé pour la migration ASP.NET 1.1 vers 2.0. Cette migration permet d’utiliser toutes les fonctionnalités ASP.NET 2.0 tout en étant dans un mode projet et donc compilation en une dll unique
Migration vers le nouveau mode de projet "Web Site Project". Cette migration est plus délicate dans la mesure où peuvent survenir des problèmes lors de l’exécution causés par le fait que nous n’avons plus maintenant une dll unique mais plusieurs dlls

Par exemple, le code behind d’une page Web peut vouloir instancier un contrôle utilisateur avec LoadControl() ou bien instancier une autre page Web à partir de son nom de classe (Webform2 par exemple). Ce code ne fonctionnera pas directement parce que les classes ne sont plus dans la même dll
De la même façon, une classe de l’application ne pourra pas instancier une classe d’une page Web parce que la dll contenant les classes ne référence pas la dll contenant les pages Web

D’autres points, ne provoquant pas des erreurs, sont à noter et à tester comme par exemple la présence des fichier .resx devenus inutiles.

Des tests et retours d’expérience ont permis de lister ces points. Je vous encourage à lire le document suivant : Common Web Project Conversion Issues and Solutions - http://msdn2.microsoft.com/en-us/library/aa479312.aspx

Voici les ressources utiles sur ce sujet :

Upgrading VS 2003 Web Projects to be VS 2005 Web Application Projects - http://webproject.scottgu.com/CSharp/Migration/Migration.aspx
Migrating - http://msdn2.microsoft.com/en-us/library/aa530793.aspx
Upgrade from ASP.NET 1.x - http://msdn2.microsoft.com/en-us/asp.net/aa336650.aspx
Migration vers "Web site project"
- Converting from Visual Studio .NET 2002 or 2003 - http://msdn2.microsoft.com/en-us/library/3z019waa(VS.80).aspx
- How to: Convert a Visual Studio .NET Project to Visual Studio 2005 - http://msdn2.microsoft.com/en-us/library/ms247241(VS.80).aspx
Migration vers "Web Application Project"
- Introduction to Web Application Projects - http://msdn2.microsoft.com/en-us/library/aa730880(vs.80).aspx
- Step-By-Step Guide to Converting Web Projects from Visual Studio .NET 2002/2003 to Visual Studio 2005 - http://msdn2.microsoft.com/en-us/library/aa479567.aspx
- Common Web Project Conversion Issues and Solutions - http://msdn2.microsoft.com/en-us/library/aa479312.aspx
- ASP.NET 2.0 Migration Overview - http://msdn2.microsoft.com/en-us/library/ms227549(vs.80).aspx

Concernant la pré-compilation, voici le point de départ : Selecting a Precompilation Model - http://msdn2.microsoft.com/en-us/library/ms227430(vs.80).aspx