Fonctions cachées d'ASP.NET

Question

Cette question existe parce qu'elle a une signification historique, mais elle n'est pas considérée comme une bonne question, sur le sujet pour ce site, donc ne l'utilisez pas comme preuve que vous pouvez poser des questions questions similaires ici.

Plus d'informations : https://stackoverflow.com/faq

---

Il existe toujours des fonctionnalités qui seraient utiles dans des scénarios marginaux, mais c'est précisément pour cette raison que la plupart des gens ne les connaissent pas. Je demande des fonctionnalités qui ne sont généralement pas enseignées dans les manuels.

Quels sont ceux que vous connaissez ?

Answer 1

Pendant les tests, vous pouvez faire en sorte que les courriels soient envoyés à un dossier sur votre ordinateur plutôt qu'à un serveur SMTP. Mettez ceci dans votre web.config :

<system.net>
    <mailSettings>
        <smtp deliveryMethod="SpecifiedPickupDirectory">
            <specifiedPickupDirectory pickupDirectoryLocation="c:\Temp\" />
        </smtp>
    </mailSettings>
</system.net>

Answer 2

Si vous placez un fichier nommé app_offline.htm dans le répertoire Root d'une application web, ASP.NET 2.0+ arrêtera l'application et cessera de traiter normalement toute nouvelle demande entrante pour cette application, en affichant uniquement le contenu du fichier app_offline.htm. pour toutes les nouvelles demandes .

Il s'agit du moyen le plus rapide et le plus simple d'afficher l'avis "Site temporairement indisponible" lors du redéploiement (ou du retour en arrière) des modifications sur un serveur de production.

En outre, comme l'a souligné marxidad Pour que le fichier soit correctement rendu par IE6, assurez-vous qu'il contient au moins 512 octets de contenu.

Answer 3

throw new HttpException(404, "Article not found");

Cela sera détecté par ASP.NET qui renverra la page customErrors. J'ai appris l'existence de celle-ci dans un récent billet sur l'astuce du jour de .NET

Answer 4

Voici le meilleur. Ajoutez ceci à votre web.config pour une compilation BEAUCOUP plus rapide. C'est le post 3.5SP1 via ce QFE .

<compilation optimizeCompilations="true">

Résumé rapide : nous introduisons un nouveau commutateur optimizeCompilations dans ASP.NET qui peut améliorer considérablement la vitesse de compilation dans certains scénarios. Il y a quelques pièges, alors lisez la suite pour plus de détails. Ce commutateur est actuellement disponible en tant que QFE pour 3.5SP1, et fera partie de VS 2010.

Le système de compilation ASP.NET adopte une approche très conservatrice qui qui l'amène à effacer tout travail antérieur travail qu'il a effectué chaque fois qu'un fichier de niveau" est modifié. Les fichiers de "niveau supérieur incluent tout ce qui se trouve dans bin et App_Code, ainsi que global.asax. Bien que cela fonctionne bien pour les petites applications, il devient presque inutilisable pour les très grandes applications. Par exemple, un client s'est retrouvé dans un cas cas où il fallait 10 minutes pour rafraîchir une page après avoir apporté une modification à un assemblage "bin".

Pour soulager la douleur, nous avons ajouté une mode de compilation "optimisé" qui qui adopte une approche beaucoup moins conservatrice de la recompilation.

Via aquí :

Answer 5

• HttpContext.Current vous donnera toujours accès à la demande/réponse/etc. du contexte actuel, même si vous n'avez pas accès aux propriétés de la page (par exemple, à partir d'une classe d'aide faiblement couplée).

• Vous pouvez continuer à exécuter du code sur la même page après avoir redirigé l'utilisateur vers une autre page en appelant Response.Redirect( url , faux )

• Vous n'avez pas besoin .ASPX si tout ce que vous voulez est un fichier compilé Page (ou tout IHttpHandler ). Il suffit de définir le chemin et les méthodes HTTP pour qu'ils pointent vers la classe dans le fichier <httpHandlers> élément dans le fichier web.config.

• A Page peut être récupéré à partir d'un .ASPX de manière programmatique en appelant PageParser.GetCompiledPageInstance(virtualPath,aspxFileName,Context)