Compatibilité entre Web Forms Mobile ASP.NET et ASP.NET
Lorsque vous créez des pages Web Forms mobiles ASP.NET, vous pouvez utiliser pratiquement toutes les fonctionnalités ASP.NET. Cependant, vous devez au préalable prendre en considération les problèmes de compatibilité.
Gestion d'erreurs et rapport d'erreurs
Lorsqu'une application ASP.NET rencontre une exception non gérée ou toute autre erreur lors du traitement d'une demande, elle génère une page d'erreurs. Les exceptions peuvent se produire à tout moment durant le traitement d'une demande. Par exemple, elles peuvent se produire lors de la lecture d'un fichier de configuration (Web.config), lors de la compilation d'une page ou de son exécution.
Vous pouvez configurer votre application de manière à générer des pages d'erreurs par défaut ou personnalisées. Si vous configurez votre application pour générer des pages d'erreurs par défaut, ASP.NET définit un code d'erreur dans la réponse et affiche une page décrivant l'erreur en détail. Cependant, si vous configurez votre application pour générer des pages d'erreurs personnalisées, chaque demande erronée est redirigée vers une page personnalisée prévue à cet effet.
De nombreux périphériques mobiles ne peuvent pas afficher le contenu détaillé d'une page d'erreurs. En règle générale, ces périphériques affichent plutôt un message d'erreur spécifique au périphérique, voire le code d'erreur. Pour répondre à cette situation, les pages Web Forms mobiles ASP.NET tentent de mettre en forme la page d'erreurs pour qu'elle s'affiche sur le périphérique. Cependant, ce rendu spécifique au périphérique se limite aux exceptions qui se produisent lors de l'exécution de la page. Par conséquent, si vous utilisez des pages d'erreurs par défaut, testez d'abord l'affichage de votre page Web Forms mobile à partir d'un navigateur de bureau, afin de détecter les erreurs potentielles de configuration ou de compilation.
Si vous envisagez d'utiliser des pages d'erreurs personnalisées dans votre application Web mobile ASP.NET, ASP.NET peut mettre en forme la page d'erreurs de manière appropriée pour différents périphériques mobiles, à condition que vous écriviez vos pages d'erreurs personnalisées à l'aide de contrôles mobiles.
Pour plus d'informations sur les pages d'erreurs dans ASP.NET, consultez la propriété ErrorPage. Pour plus d'informations sur la gestion des erreurs, consultez Gestion de rapport d'erreurs adaptable dans les pages Web mobiles ASP.NET.
Traçage
ASP.NET offre une fonctionnalité simple d'utilisation, le traçage, que vous pouvez utiliser pour déboguer vos applications Web. ASP.NET fournit deux niveaux de traçage, le traçage au niveau de la page et celui au niveau de l'application. Le traçage au niveau de la page apporte des informations de traçage sous forme de code HTML ajouté à chaque page suivie. En revanche, le traçage au niveau de l'application apporte des informations de traçage via une URL mappée particulière (Trace.axd) dans l'application.
Si vous utilisez le traçage au niveau de la page dans votre application Web mobile ASP.NET, le code HTML ajouté au rendu peut empêcher la sortie de s'effectuer sur le périphérique mobile. Pour les applications Web mobiles ASP.NET, vous devez plutôt utiliser un traçage au niveau de l'application et inspecter la sortie de la trace à partir d'un navigateur Web de bureau.
Pour plus d'informations sur les fonctionnalités de traçage ASP.NET, consultez Traçage ASP.NET.
État de session et cookies
ASP.NET offre de nombreuses fonctionnalités de gestion de session, qui vous permettent de conserver facilement un état sur plusieurs demandes. En règle générale, la fonctionnalité d'état de session ASP.NET utilise des cookies avec le navigateur, mais elle peut être configurée pour fonctionner sans cookies.
Dans ASP.NET, vous pouvez utiliser Session pour enregistrer des informations relatives à une session utilisateur sur plusieurs demandes. La gestion de session dans ASP.NET est évolutive et solide ; par conséquent, vous pouvez même l'utiliser avec des batteries de serveurs Web. Par défaut, le Session ASP.NET utilise un cookie côté client pour stocker un identificateur sur l'ordinateur du client. Vous pouvez utiliser cet identificateur pour localiser une session au cours des accès répétés au serveur. En outre, le Session ASP.NET prend en charge un mode de session sans cookies, qui redirige initialement un client vers une nouvelle URL contenant l'identificateur d'une session. L'identificateur de session est alors automatiquement analysé à partir de l'URL.
Lorsque vous écrivez une application Web mobile ASP.NET, n'oubliez pas qu'il existe des périphériques mobiles et des passerelles sans fil qui ne prennent pas en charge les cookies. Pour ajouter une prise en charge de ces périphériques, vous devez configurer votre application de manière à utiliser les sessions sans cookies.
Pour plus d'informations sur les fonctionnalités de gestion de session ASP.NET, consultez Gestion d'état ASP.NET.
Considérations sur l'utilisation de l'état de session
Lorsque vous écrivez une application Web mobile ASP.NET utilisant la gestion d'état de session, prenez en compte les facteurs suivants :
L'utilisation de contrôles ASP.NET dans l'espace de noms System.Web.UI.WebControls sur une page Web Forms mobile n'est pas prise en charge. Les pages Web Forms mobiles qui utilisent les contrôles Web mobiles dans l'espace de noms System.Web.UI.MobileControls prennent en charge l'attribut EnableSessionState de la directive @ Page avec la valeur false. Toutefois, les pages Web Forms mobiles qui utilisent un contrôle ASP.NET de l'espace de noms System.Web.UI.WebControls avec EnableSessionState avec la valeur false peuvent entraîner une erreur de compilation.
Certains périphériques et passerelles mobiles ne prennent pas en charge les cookies. Pour permettre l'exécution d'une page Web Forms mobile ASP.NET sur ces périphériques, l'attribut cookieless de l'élément sessionState doit avoir la valeur true.
Certains périphériques mobiles ont des problèmes pour gérer les URL relatives, une fois qu'elles sont redirigées via la technique de gestion de session sans cookies.
Par exemple, si un navigateur Openwave ouvre un fichier .aspx situé sur https://localhost/a.aspx, et si le site Web redirige le navigateur vers /12345678/a.apsx, le navigateur continue de considérer son chemin d'accès actuel comme la racine. Le navigateur demande une référence relative ultérieure à b.aspx en tant que /b.aspx.
La solution consiste à inclure une URL associée à une racine sur la page, par exemple /12345678/a.aspx, au lieu d'une URL relative, lorsqu'un rendu a lieu après une redirection. Les contrôles mobiles ASP.NET intégrés le font automatiquement. En revanche, tous les nouveaux contrôles ou adaptateurs écrits doivent inclure le code de gestion d'un rendu après une redirection. MobilePage et les classes de base d'adaptateur possèdent des méthodes, telles que MakePathAbsolute, qui permettent à un développeur de contrôle mobile d'écrire des URL associées à des racines.
Utilisation des redirections
Certains périphériques et navigateurs nécessitent actuellement des URL qualifiées complètes en réponse à une redirection HTTP. Affectez la valeur true à l'attribut useFullQualifiedRedirectUrl de l'élément httpRuntime dans la section System.Web du fichier Machine.config ou du fichier Web.config (au niveau de l'application). Pour plus d'informations, consultez Redirection vers une page Web mobile ASP.NET.
Problèmes de syntaxe
La syntaxe valide dans ASP.NET, par exemple <%=, ne l'est pas dans les contrôles mobiles ASP.NET. Par conséquent, elle doit être remplacée par des mécanismes de liaison de données.
Les expressions de liaison de données doivent être délimitées par <%# et %>. Voici un exemple d'utilisation d'expression de liaison de données.
<%# binding expression code goes here %>
Voir aussi
Référence
Concepts
Gestion de rapport d'erreurs adaptable dans les pages Web mobiles ASP.NET
Redirection vers une page Web mobile ASP.NET
Autres ressources
Traçage ASP.NET
Gestion d'état ASP.NET
Mise en route des contrôles mobiles ASP.NET