Dépannage de la conversion vers Visual Web Developer

Article
10/22/2014

Mise à jour : novembre 2007

Lorsque vous utilisez Microsoft Visual Web Developer pour ouvrir un projet d'application Web qui a été créé à l'aide de versions antérieures de Microsoft Visual Studio .NET, Visual Web Developer convertit automatiquement l'application Web au format utilisé dans ASP.NET version 2.0.

Remarque :
Pour plus d'informations sur le processus de conversion, consultez Conversion d'un projet Web de Visual Studio .NET.

Dans certaines circonstances, vos applications Web se comporteront différemment après la conversion. Cette rubrique décrit les situations généralement rencontrées et suggère des solutions. Pour plus d'informations sur la résolution des problèmes de migration, vous pouvez également consulter des informations concernant la migration sur le site ASP.NET Development Center for Migration.

Cette rubrique traite des problèmes de conversion suivants :

Les contrôles restituent un balisage différent après la conversion
La validation du balisage génère des erreurs
Les événements de page sont déclenchés deux fois après la conversion
Classes ambiguës signalées pendant la compilation
Erreurs liées aux modifications dans le modèle de page code-behind
Erreur d'analyse
Des fichiers exclus ne sont plus exclus
Solutions partiellement converties pour les types de projets mixtes
Ouverture d'un site de type Web en tant que site de système de fichiers
Les ID client sont supprimés du fichier code-behind
Erreur de référence circulaire

Les contrôles restituent un balisage différent après la conversion

Dans ASP.NET 2.0, sauf si le navigateur est identifié comme ne prenant pas en charge les fonctionnalités XHTML, la classe Page et les contrôles serveur Web ASP.NET restituent le balisage par défaut, conforme à la norme XHTML 1.0 Transitionnel. L'Assistant Conversion affecte automatiquement à l'attribut mode de l'élément xhtmlConformance la valeur Legacy. Au terme de la conversion, la restitution des éléments peut être légèrement différente de celle des versions antérieures d'ASP.NET. Dans la plupart des cas, les différences dans la restitution n'ont aucun effet sur les fonctionnalités de l'application. Toutefois, si vous avez un script client qui s'appuie sur des balises ou des attributs spécifiques, votre application peut ne pas fonctionner comme avant.

Pour plus d'informations, consultez ASP.NET et XHTML.

La validation du balisage génère des erreurs

Après la migration, le schéma de validation du balisage par défaut a la valeur Internet Explorer 6.0. Cela signifie que l'éditeur compare le balisage de votre page à un schéma qui définit le code HTML considéré comme valide par Microsoft Internet Explorer 6.0. Cette étape a pour but de simplifier la transition vers Visual Web Developer. Il est conseillé de modifier votre balisage afin que vos pages d'application effectuent une validation à l'aide du schéma de validation XHTML 1.0 Transitional.

Pour plus d'informations sur la modification du schéma de validation, consultez Comment : sélectionner des schémas de validation pour l'édition HTML dans Visual Web Developer.

Les événements de page sont déclenchés deux fois après la conversion

Le processus de conversion supprime l'attribut AutoEventWireup de la directive @ Page. La valeur par défaut de cet attribut est true, ce qui signifie que la page déclenche automatiquement des événements qui portent le nom Page_ event. Si une page affecte explicitement false à l'attribut AutoEventWireup après la conversion, les événements sur la page seront déclenchés automatiquement. Si la page inclut une autre façon explicite de déclencher l'événement, telle que le mot clé Handles en Visual Basic, l'événement peut être déclenché deux fois. Pour résoudre ce problème, ajoutez AutoEventWireup="false" à la directive @ Page.

Classes ambiguës signalées pendant la compilation

Après avoir converti un projet, il est possible que le compilateur signale qu'une classe est ambiguë, ce qui signifie qu'elle a été importée de plusieurs espaces de noms. Par exemple, si un projet converti crée une instance de la classe Cache, le compilateur signale que la classe réside dans les espaces de noms System.Net et System.Web.Caching.

Dans des cas semblables, le .NET Framework version 2.0 contient une nouvelle classe qui porte le même nom qu'une classe existante. Pour résoudre ce problème, recherchez dans votre code des références à la classe, puis faites précéder le nom de classe du nom de l'espace de noms, créant une référence qualifiée complète.

Erreurs liées aux modifications dans le modèle de page code-behind

La conversion de projets à l'aide de pages .aspx ayant accès à des membres protégés de classe dans les classes code-behind peut générer des exceptions. C'est la modification du modèle code-behind dans le .NET Framework version 2.0 qui en est la cause. Dans les versions précédentes du .NET Framework, les pages étaient des classes dérivées des classes code-behind. Toutefois, dans ASP.NET 2.0, les classes code-behind définissent des classes partielles qui sont utilisées avec la page .aspx pendant la génération de page pour créer la page compilée résultante.

Un scénario classique illustrant ce type de problème de conversion est une application qui définit des composants de disposition partagés dans une classe code-behind d'une classe de base. Vous pouvez obtenir les mêmes fonctionnalités de disposition partagées en recourant aux contrôles utilisateur ou aux pages maîtres, ou en utilisant l'attribut CodeFileBaseClass de la directive @ Page. Pour plus d'informations sur le développement de contrôles utilisateur, consultez Vue d'ensemble des contrôles utilisateur ASP.NET. Pour plus d'informations sur l'utilisation des pages maîtres, consultez Vue d'ensemble des pages maîtres ASP.NET.

Erreur d'analyse

L'Assistant Conversion signale les erreurs d'analyse sur les fichiers .aspx qui n'ont pas pu être analysés. Les causes des problèmes d'analyse peuvent être classées dans plusieurs catégories :

La page .aspx n'a pas été mise en forme correctement avant l'exécution de l'Assistant Conversion.
Un attribut CodeBehind ou Src de la directive @ Page était introuvable.
Le fichier code-behind référencé dans une page .aspx était introuvable.
Un fichier .aspx est répertorié dans le fichier projet (par exemple, .csproj ou .vbproj), mais pas dans le répertoire du projet. Si le fichier ne fait pas partie du projet, cette erreur peut être ignorée.

Des fichiers exclus ne sont plus exclus

Dans les versions antérieures de Visual Studio, vous aviez la possibilité d'inclure ou d'exclure des fichiers d'un projet Web. En outre, un fichier pouvait être exclu de la génération de projet par l'affectation de la valeur None à son action de génération. L'Assistant Migration traite ces deux cas différemment. L'Assistant Migration convertit les fichiers d'un projet Web qui ne sont pas marqués comme étant exclus. L'Assistant Migration ne convertit pas les fichiers qui ne font pas partie de la génération de projet, à savoir les fichiers configurés avec leur action de génération affectée de la valeur None.

Au terme du processus de conversion, vous pouvez supprimer tous les fichiers précédemment exclus ou les renommer avec une extension qui n'est pas utilisée dans Visual Studio, telle que l'extension .exclude. Si un fichier d'un projet dans le projet Web n'a pas été converti, vérifiez que son action de génération n'a pas la valeur None.

Les fichiers dont l'action de génération associée a la valeur None génèrent un message d'erreur dans le rapport de conversion. Pour plus d'informations sur le rapport de conversion, consultez Format du rapport de conversion généré à l'issue de la migration.

Solutions partiellement converties pour les types de projets mixtes

Dans Microsoft Visual Studio 2005 et les versions antérieures, il est possible d'avoir une solution composée de projets Web et de projets clients, tels que les bibliothèques de classes ou les applications Windows. Si vous utilisez une édition Express de Microsoft Visual Studio 2005, seule la partie de la solution qui se rapporte à l'édition Express peut être convertie. Si, par exemple, vous utilisez l'Assistant Conversion dans Visual Web Developer 2005 Express, vous serez uniquement en mesure de convertir les projets Web des solutions que vous ouvrez, indépendamment des autres types de projets contenus dans la solution. La solution convertie résultante ne sera que partiellement convertie. Pour convertir complètement une solution qui contient des types de projets mixtes, utilisez Visual Web Developer 2005, Visual Studio 2005 ou Visual Studio 2005 Team System.

Ouverture d'un site de type Web en tant que site basé sur des fichiers

La méthode recommandée pour ouvrir un site Web créé dans une version antérieure de Visual Studio consiste à utiliser l'option de menu Ouvrir le Site Web dans Visual Web Developer 2005. Vous pouvez ensuite décider d'ouvrir le site comme un site basé sur des fichiers, un site Microsoft Internet Information Services (IIS) local, un site déployé sur FTP (File Transfer Protocol) ou un site distant. L'ouverture d'un site de type Web comme un site basé sur des fichiers entraîne la perte des informations sur les métadonnées IIS. Les informations concernant les sous-dossiers marqués comme répertoires virtuels, notamment, ne sont pas conservées. Le rapport de conversion signale un avertissement lorsqu'un site de type Web est converti en site basé sur des fichiers.

Il est recommandé de fermer le site Web, de le rouvrir à l'aide de la commande Ouvrir le site Web et de sélectionner l'onglet Serveur IIS local. Pour plus d'informations sur l'utilisation de l'Assistant Migration, consultez Comment : convertir un projet Visual Studio .NET vers Visual Studio 2005. Pour plus d'informations sur le rapport de conversion, consultez Format du rapport de conversion généré à l'issue de la migration.

Les ID côté client sont supprimés du fichier code-behind

Si votre balisage utilise un attribut ID côté client (par exemple dans un élément div HTML) qui porte le même nom qu'une variable membre déclarée dans la page code-behind, la balise ID du balisage est supprimée au cours de la conversion.

Pour résoudre ce problème, examinez votre balisage et votre code avant la conversion et recherchez des conflits de noms entre les attributs ID côté client et les variables membres. Modifiez-les afin qu'ils utilisent des noms différents.

Erreurs de référence circulaire

Le processus de conversion ajoute des directives @ Reference aux pages code-behind qui référencent d'autres pages ou contrôles utilisateur. Dans certains cas, cela crée une référence circulaire. Pour résoudre le problème, vous pouvez affecter la valeur False à l'attribut batch de l'élément compilation. La valeur par défaut de l'attribut batch est True. L'affectation de la valeur False peut parfois éliminer les problèmes de référence circulaire. À plus long terme, vous pouvez revoir la conception des pages ou des contrôles utilisateur afin qu'ils utilisent une classe de base abstraite définie dans une classe stockée dans le dossier App_Code et redéfinir l'attribut batch pour qu'il ait la valeur True.

Voir aussi

Partager via