IIS 6 : erreur 404 sur fichier sans extension

Le problème du jour : après avoir déployé mon projet sur un serveur Windows 2003, je me trouve face à une erreur 404 lorsque je souhaite accéder à un fichier se trouvant sur mon serveur. Après avoir fait les vérifications d'usages (présence du fichier, droits d'accès), le problème semble plus compliqué que ce qu'il ne pouvait paraître.

Il se trouve que ce fichier est sans extension, forcément cela n'est pas un hasard, je rajoute donc une extension à mon fichier et l'erreur 404 disparait. Je me dis que cela a surement à voir avec les types MIME, j'essaye donc un paramétrage avec l'extension "." mais sans succès. Je me tourne donc vers mon ami Google, et voici le lien qui m'apporta la solution.

En résumé, il suffit de créer un type MIME "application/octet-stream" sur l'extension ".*". Voici la copie d'écran de ce que cela donne sous IIS :

Modification :
Avec un tel paramétrage je rencontre un gros problème avec Google Chrome : les fichiers CSS ne passe plus !
Donc retour arrière une fois de plus, à la place du ".*", il suffit de mettre "." en gardant le même type MIME et là plus de soucis (apparemment en tout cas). S'il n'y a pas de modification à ce billet c'est que cela fonctionne.

RadAnsyncUpload et DNN

Un petit billet suite à un problème rencontre avec le contrôle "RadAsyncUpload" de Telerik sous DotNetNuke.

Une petite présentation concernant ce contrôle pour ceux qui ne connaitraient pas : ce contrôle permet de remonter des fichiers de façon asynchrone sur le serveur. Exemple d'utilisation : vous souhaitez donner la possibilité à vos utilisateur de remonter des fichiers images sur votre site et de les visualiser dans la foulée sur la même page sans valider cette dernière (pas de postback donc).

Après avoir mis en place ce contrôle dans un module DNN, je me trouvais face à joli problème : chaque upload de fichier tombait en erreur (un point d'exclamation rouge à gauche du nom du fichier). Aucun événement serveur ne se levait et sur le client l'évément "onClientFileUploadFailed" se levait bien mais la méthode "args.get_serverResponse()" ne retournait aucune erreur (voir ce message sur le forum de Telerik).

Pourtant j'avais déjà utilisé ce contrôle sous DNN avec succès sous un autre projet. Alors pourquoi cela a-t-il déjà marché et cela ne marche-t-il plus ? En fait le projet sous lequel le contrôle marchait avait une particularité : les utilisateurs ne s'identifiaient pas ! La clef était là, en effet si je ne m'identifiais pas le contrôle fonctionnait sinon il y avait systématiquement l'erreur.

Me voilà donc rendu à éplucher le module de connexion DNN, et après avoir désactivé chaque ligne j'ai enfin trouvé LA cause du problème : Response.Redirect(..., True). Dans le module de connexion, une fois que l'utilisateur est identifié, une redirection est effectuée avec le paramètre "True" (indiquant que le traitement de la page en-cours doit s'arrêter). En passant ce paramètre à "False", plus de problème.

Heureusement pour moi j'avais mon propre module de connexion, donc pas de soucis pour modifier cela. Si ce n'est pas votre cas... vous savez ce qu'il vous reste à faire.

Visual Studio 2010 - Désactiver le débugage de script (Script Debugging)

Sous Visual Studio 2010 (Idem pour 2008), lorsque vous exécuter un projet web ASP.NET vous voyez rapidement "débouler" dans votre explorateur de solution une nouvelle branche "Documents de Script" dont le contenu varie suivant la page où vous vous trouvez. Ces informations permettent de déboguer le javascript se trouvant sur vos pages, le gros inconvénient c'est que cela ralenti sensiblement VS.

Pour désactiver cette affichage, vous devez mettre à jour une clef en base de registre. Et tant qu'a faire compliquer autant y aller jusqu'au bout : suivant que vous êtes sous un OS 32 ou 64 bits la méthode à suivre pour désactiver ou réactiver cette fonctionnalité est différente.

Sur un OS 32 bits, utiliser la commande "cmd" que vous devez bien connaitre pour ouvrir une fenêtre DOS. Sur un OS 64 bits, il vous faut utiliser le command prompt 32 bits voilà pourquoi vous lancerez plutôt "c:\windows\syswow64\cmd.exe".

Ensuite les commandes sont identiques que vous soyez en 32 ou 64 bits :

• pour désactiver la fonctionnalité :

reg add HKLM\SOFTWARE\Microsoft\VisualStudio\10.0\AD7Metrics\Engine\{F200A7E7-DEA5-11D0-B854-00A0244A1DE2} /v ProgramProvider /d {4FF9DEF4-8922-4D02-9379-3FFA64D1D639} /f

• pour réactiver la fonctionnalité :

reg add HKLM\SOFTWARE\Microsoft\VisualStudio\10.0\AD7Metrics\Engine\{F200A7E7-DEA5-11D0-B854-00A0244A1DE2} /v ProgramProvider /d {170EC3FC-4E80-40AB-A85A-55900C7C70DE} /f

Si vous êtes sous Visual Studio 2008, remplacez le 10.0 par 9.0.

Pensez à faire ces manipulations avec VS fermé.

Retour sur les gestion des erreurs dans un UserControl

Bans mon précédent billet, je faisais référence à la gestion des erreurs dans un UserControl. Et bien retour arrière, la méthode décrite par Cyril ne me donnant pas satisfaction (toutes les erreurs n'étant pas catchées), je reviens à la bonne vieille méthode du try - catch que l'on met en place dans chaque événement.

Ce n'est pas compliqué en soit, il faut juste y penser.