Toutes les demandes de ASP.NET l'API Web de retour d'erreur 404

J'ai un ASP.NET MVC 4 web site Web de l'API. Le site est développé et testé avec Visual Studio 2012 et .NET 4.5 sur Windows 8 avec IIS Express en tant que serveur web. Dans cet environnement de développement tout fonctionne.

Maintenant, il est déployé sur un Windows 2008 R2 (SP1) Server avec IIS 7.5. .NET 4.0 et 4.5 sont installés. Le pool d'applications est en cours d'exécution .NET 4.0 intégrées dans le mode de pipeline.

Dans cet environnement de production MVC web site Web de l'API ne fonctionne pas. Pour chaque requête, peu importe si GET ou POST j'ai une erreur 404. Si je viens d'entrer dans une API Web de l'Url dans le navigateur (IE 9 a ouvert localement sur le serveur) pour exécuter une requête GET-je obtenir une page 404. Si je l'envoi d'une requête POST à partir d'une API Web application cliente j'obtiens une erreur 404 comme le bien et le message:

Pas HTTP ressource a été trouvée, qui correspond à l'URI de la demande

J'ai créé un site web de test avec MVC 4 et Web API et déployé sur le même serveur et le Web API travaille. L'API Web et MVC assemblées ont le même numéro de version dans les deux projets.

En outre, j'ai ajouté le Web API Route Débogueur à l'application. Si j'utilise un valide route comme http://myserver/api/order/12 j'obtiens le résultat suivant:

Toutes les demandes de ASP.NET l'API Web de retour d'erreur 404

Pour moi, cela signifie que le bon template de route Api/{Controller}/{Id} a été trouvé et correctement analysé dans un contrôleur de Order et Id=12. Le contrôleur (dérivé de ApiController) existe dans le site web de l'assemblée où l'ensemble des contrôleurs MVC sont.

Cependant, je ne sais pas quel est le statut 000 pourrait dire et pourquoi il n'y a pas de "Route de la sélection de" section affichée (ce qui est normalement le cas, même si l'assemblée ne contient pas une seule ApiController, voir les captures d'écran sur la page du lien ci-dessus). En quelque sorte il ne ressemble à aucun ApiController est trouvé ou même pas recherché ou de la recherche échoue silencieusement.

Les fichiers journaux IIS ne pas montrer quoi que ce soit d'utile. La modification de plusieurs paramètres de pool d'applications et d'utiliser le même pool d'applications pour le test et l'application réelle n'a pas aidé.

Je suis actuellement en train de supprimer les "caractéristiques", les paramètres de configuration, troisième partie, assemblées, etc. à partir de l'application pour le ramener à la petite taille de l'application de test à la fin, et en espérant qu'à un certain moment, il commence à travailler.

Est-ce que qqn a une idée de ce que peut être le problème? Aussi tout le débogage ou l'enregistrement d'idée pour éventuellement trouver la raison en est très bienvenue.

Modifier

Grâce à Darrel Miller astuce dans les commentaires ci-dessous, j'ai intégré Le suivi pour ASP.NET Web Api.

Pour l' (GET) URL de demande http://myserver/api/order/12 je reçois le texte suivant:

Dans un environnement de développement, le succès de la (dans sa forme courte):

Message: http://localhost:50020/api/order/12; Catégorie:
Système.Web.Http.Demande

Contrôleur de la sélection et de l'instanciation...

Opérateur: DefaultHttpControllerSelector; Opération: SelectController;
Message: Route="contrôleur:à l'ordre,id:12"; Catégorie:
Système.Web.Http.Les contrôleurs de

Opérateur: DefaultHttpControllerSelector; Opération: SelectController;
Message: De L'Ordre; Catégorie: Système D'.Web.Http.Les contrôleurs de

Opérateur: HttpControllerDescriptor; Opération: CreateController;
Message: ; Catégorie: Système D'.Web.Http.Les contrôleurs de

Opérateur: DefaultHttpControllerActivator; Opération: Créer; Message:
; Catégorie: Système D'.Web.Http.Les contrôleurs de

Opérateur: DefaultHttpControllerActivator; Opération: Créer; Message:
MyApplication.ApiControllers.OrderController; Catégorie:
Système.Web.Http.Les contrôleurs de

Sélection de l'Action, le paramètre de liaison et d'action invocation suivante...

La négociation de contenu et mise en forme pour la suite...

Opérateur: DefaultContentNegotiator; Opération: Négocier; Message: Typ = "String" ...
plus

De disposer du contrôleur...

Opérateur: OrderController; Opération: Disposer; Message: ; Catégorie:
Système.Web.Http.Les contrôleurs de

En environnement de production, pas de succès (dans sa forme courte):

Message: http://myserver/api/order/12; Catégorie:
Système.Web.Http.Demande

Opérateur: DefaultHttpControllerSelector; Opération: SelectController;
Message: Route="contrôleur:à l'ordre,id:12"; Catégorie:
Système.Web.Http.Les contrôleurs de

La partie entière de contrôleur de l'activation, la sélection de l'action, les paramètres de la liaison, l'action de l'invocation est manquant et il suit de contenu
la négociation et la mise en forme du message d'erreur immédiatement:

Opérateur: DefaultContentNegotiator; Opération: Négocier; Message:
Type = "HttpError" ... plus

Vous pourriez avoir à activer certaines fonctionnalités IIS dans les Rôles de Serveur > Internet Services d'Informations > Services World Wide Web. Je ne sais pas exactement ce que vous devez l'activer mais je pense que votre problème peut être ici !
Essayez de tourner sur le Web, le suivi de l'API asp.net/web-api/overview/testing-and-debugging/...
On dirait que votre WebAPI n'est pas enregistré. ce qui se passe avec votre Global.asax et WebApiConfig? Ont-ils une sorte de mise en configuration de l'intérieur de lui?
Merci! C'était un bon conseil. Cependant: je n'ai toujours pas d'explication à la sortie de trace. J'ai ajouté à ma question.
Il y a juste la route par défaut Api/{controller}/{id} avec id par défaut RouteParameter.Optional. Comme l'a dit, il fonctionne dans l'environnement de dev. Serait-il fonctionner si l'API Web routes ne sont pas enregistrés?
J'ai remarqué que le Produit de l'Environnement a l'Neogiate opération avec HttpError type. Quelle erreur voyez-vous, quand vous faites une demande? Pouvez-vous essayer de définir config.IncludeErrorDetailPolicy comme Always et voir ce qu'il dit? Aussi, je suis soupçonner, il pourrait être un problème dans la résolution des assemblages si tous les ensembles ne sont pas présents dans votre environnement de production. Pour voir si c'est le cas, vous pourriez faire quelque chose dont j'ai parlé dans ce post: stackoverflow.com/questions/16673851/...
Avez-vous configuré correctement les liaisons dans IIS pour le site? Il est peut-être ridicule de suggestion, mais si le serveur est à la recherche dans le mauvais dossier, car les liaisons sont incorrectes, vous atteindrez 404.
Grand, grand merci!!!!!! C'était un manque de l'assemblée (voir ma réponse ci-dessous). Vous pouvez poster votre commentaire à propos de la résolution de l'assemblée et un lien vers votre post est une réponse? Je vais l'accepter. BTW: pensez-vous qu'il s'agit d'une amélioration de ce "Nous avons délibérément ignorer toutes les exceptions..." dans le cadre de l'API du Web source possible 🙂
Heureux qui a aidé!!...ouais, moi aussi, je pense que l'expérience devrait être améliorée que de nombreux utilisateurs semblent être de prendre ce problème...Pourriez-vous s'il vous plaît fichier un problème ici? : aspnetwebstack.codeplex.com/workitem/list/basic
J'ai signalé ici: aspnetwebstack.codeplex.com/workitem/1075 Merci encore 🙂
Je happenned pour supprimer le mondial.asax fichier et que la cause de ce problème. espérons que cela aide quelqu'un\

InformationsquelleAutor Slauma | 2013-05-29

23

Grâce à Kiran Challa est commentaire et le code source de cette réponse j'ai été en mesure de comprendre qu'une assemblée (le ReportViewer 11 assembly pour SQL Server Reporting Services) était manquant sur le serveur de production.

Bien qu'aucune ApiController est dans cette assemblée, il semble provoquer que les contrôleurs dans les assemblages - dans ce cas, mon projet Web de l'assemblée - qui sont la référence à l'assembly manquant ne sont pas trouvés.

Apparemment, ce comportement est lié à ce morceau de code à partir de la Web API DefaultHttpControllerTypeResolver source:
```
List<Type> result = new List<Type>();

//Go through all assemblies referenced by the application
//and search for types matching a predicate
ICollection<Assembly> assemblies = assembliesResolver.GetAssemblies();
foreach (Assembly assembly in assemblies)
{
    Type[] exportedTypes = null;
    if (assembly == null || assembly.IsDynamic)
    {
        //can't call GetExportedTypes on a dynamic assembly
        continue;
    }

    try
    {
        exportedTypes = assembly.GetExportedTypes();
    }
    catch (ReflectionTypeLoadException ex)
    {
        exportedTypes = ex.Types;
    }
    catch
    {
        //We deliberately ignore all exceptions when building the cache. If 
        //a controller type is not found then we will respond later with a 404.
        //However, until then we don't know whether an exception at all will
        //have an impact on finding a controller.
        continue;
    }

    if (exportedTypes != null)
    {
        result.AddRange(exportedTypes.Where(x => IsControllerTypePredicate(x)));
    }
}
```
Je ne sais pas si elle a à être de cette façon et je ne suis pas tout à fait convaincu par le commentaire dans le code, mais ce catch ... continue bloc est assez silencieux à propos d'un éventuel problème et il m'a fallu une énorme quantité de temps et de frustration pour le trouver. Je savais même que le ReportViewer n'était pas encore installé. J'ai essayé de l'installer et dépendante assemblées, mais il a été bloqué par un autre processus en cours d'exécution sur le serveur, j'ai donc décidé de reporter l'installation jusqu'à ce que je pouvais communiquer avec l'administrateur et de se concentrer sur MVC et WebAPI tests de première grosse erreur! Sans Kiran de débogage de l'extrait de code que je n'avais jamais eu l'idée que l'existence d'un ReportViewer.dll pourrait avoir quelque chose à voir avec le type de contrôleur de résolution.

À mon avis, il y a place à l'amélioration pour le développeur moyen comme moi qui n'ont pas de connaissances approfondies sur le fonctionnement interne de l'API Web.

Après l'installation du manque ReportViewer.dll le problème a disparu.

Voici des questions sur le même symptôme, qui pourrait avoir la même raison:
Modifier

J'ai émis une demande d'amélioration sur CodePlex:

http://aspnetwebstack.codeplex.com/workitem/1075

Edit 2 (Août 11 '13)

Le problème a été corrigé pour WebAPI v5.0 RC. Voir le lien ci-dessus pour la workitem et ses commentaires de l'article pour plus de détails.
- Où trouvez-vous cette Assemblée? Je ne vois que des choses pour les formulaires web.
- Il fait partie de la mon projet. Si vous n'utilisez pas SSRS, vous n'aurez pas cette assemblée dans votre projet.
InformationsquelleAutor Slauma
5

De grandes ressources dans cette réponse, cependant, j'ai été faire un 404 pour ce qui s'avéra être un peu stupide raison:
1. J'ai créé un WiX programme d'installation pour mon projet API
2. Installé sur un test de la VM (machine virtuelle)
3. Demandé pour l'un URI qui l'API doit servir
4. BANG! 404 🙁
Il s'est avéré que j'avais raté l'empaquetage et déploiement de la Mondiale.asax à la racine du répertoire virtuel dans mon déploiement. L'ajout de ce ici pour le bénéfice de goofies comme moi 🙂
- La dernière phrase était un indice pour moi, et je l'ai fait travailler par la vérification de la "Pré-compiler avant...." lorsque je publie, et il fonctionne comme mon serveur local.
InformationsquelleAutor Sudhanshu Mishra

J'ai eu le même problème sur un serveur distant, mais quand je l'execute sur un localhost fonctionne très bien.

Ma solution a été:

<system.webServer>
    <modules>
        <remove name="UrlRoutingModule-4.0" />
        <add name="UrlRoutingModule-4.0" 
            type="System.Web.Routing.UrlRoutingModule" preCondition="" /> 
    </modules>
</system.webServer>

J'espère que cela fonctionne pour vous.

InformationsquelleAutor framled

Vous devez vous connecter pour publier un commentaire.