Page HTTP 404 introuvable dans l'API Web hébergée dans IIS 7.5


96

J'ai une application Web Api. Cela fonctionne parfaitement bien lorsque je l'ai testé en utilisant le serveur de développement de débogage VS 2010. Mais je l'ai maintenant déployé sur IIS 7.5 et j'obtiens une erreur HTTP 404 en essayant d'accéder à l'application.

Voici mon web.config

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <connectionStrings>
    <add name="DefaultConnection" connectionString="Data Source=.\SQLEXPRESS;Initial Catalog=aspnet-FlowGearProxy-20123141219;Integrated Security=True" providerName="System.Data.SqlClient" />
  </connectionStrings>
  <appSettings>
    <add key="webpages:Version" value="2.0.0.0" />
    <add key="webpages:Enabled" value="true" />
    <add key="PreserveLoginUrl" value="true" />
    <add key="ClientValidationEnabled" value="true" />
    <add key="UnobtrusiveJavaScriptEnabled" value="true" />
  </appSettings>
  <system.web>
    <compilation debug="true" targetFramework="4.0" />
    <authentication mode="Forms">
      <forms loginUrl="~/Account/Login" timeout="2880" />
    </authentication>
    <pages>
      <namespaces>
        <add namespace="System.Web.Helpers" />
        <add namespace="System.Web.Mvc" />
        <add namespace="System.Web.Mvc.Ajax" />
        <add namespace="System.Web.Mvc.Html" />
        <add namespace="System.Web.Routing" />
        <add namespace="System.Web.WebPages" />
      </namespaces>
    </pages>
  </system.web>
  <system.webServer>
    <validation validateIntegratedModeConfiguration="false" />
    <modules runAllManagedModulesForAllRequests="true" />
  </system.webServer>
</configuration>

2
J'ai le même problème. Je n'ai pas encore trouvé de solution, mais une chose que j'ai découverte est que si vous sélectionnez le site dans IIS, puis accédez à la fonctionnalité Mappages de gestionnaires, il existe un mappage pour les fichiers statiques qui mappe * à un fichier qui doit exister. Lorsque je supprime ce mappage et ajoute un nouveau mappage pour tous les verbes HTTP, je n'obtiens plus le 404, il est remplacé par une page blanche vierge.
Despertar

>> en utilisant le serveur de développement de débogage VS 2010. - AKA le mal Cassini. Voir blogs.msdn.com/b/rickandy/archive/2011/04/22 / ... - Si cela ne fonctionne pas, créez une nouvelle application MVC 4 WebApi et testez le déploiement - simple
RickAndMSFT

Réponses:


93

J'avais aussi du mal avec ça. Heureusement, Steve Michelotti a documenté une solution qui a fonctionné pour moi ici .

À la fin de la journée, j'ai activé tous les verbes (verb = "*") pour le gestionnaire ExtensionlessUrlHandler-Integrated-4.0 dans ma configuration Web.

<system.webServer>
    <validation validateIntegratedModeConfiguration="false" />
    <modules runAllManagedModulesForAllRequests="true" />
        <handlers>
            <remove name="ExtensionlessUrlHandler-Integrated-4.0" />
            <add name="ExtensionlessUrlHandler-Integrated-4.0" path="*." verb="*" type="System.Web.Handlers.TransferRequestHandler" resourceType="Unspecified" requireAccess="Script" preCondition="integratedMode,runtimeVersionv4.0" />
        </handlers>
</system.webServer>

D'autres ont souligné que l'activation de WebDAV pose des problèmes. Heureusement, je n'ai pas non plus rencontré ce problème.


3
+1 pour celui-là. Mais je l'ai changé dans les mappages de gestionnaire sur l'application à partir du gestionnaire IIS. Il était activé pour un tas de verbes. J'ai changé cela pour tous les verbes (*) et voila. Mais toujours mieux de mettre dans la source.
Wolf5

1
J'ai le même problème, mais ces changements ne m'ont pas aidé. Existe-t-il également une autre configuration? Ou peut-être une référence de bibliothèque? S'il vous plaît, aussi, voir: stackoverflow.com/questions/27303523/…
Babak

2
beaucoup de gens disent que l'utilisation de runAllManagedModulesForAllRequests aura un impact sur les performances (vérifiez les réponses de hemant gautam ci-dessous). Cependant, je ne peux pas obtenir le même service, je suis donc la configuration ici: blog.maartenballiauw.be/post/2012/12/07 / ... Ce lien indique également que l'activation de WebDAV peut également affecter le résultat
Hoàng Long

Réponse géniale!
EnocNRoll - AnandaGopal Pardue

1
Pour moi, le verbe était déjà *. Je devais également changer le chemin pour *le faire fonctionner car cela *.causait toujours le problème
Alsty

56

Eu le même problème. Ce paramètre de configuration a résolu le problème.

<system.webServer>
    .....
    <modules runAllManagedModulesForAllRequests="true" />
    .....
</system.webServer>

Comme expliqué dans http://www.britishdeveloper.co.uk/2010/06/dont-use-modules-runallmanagedmodulesfo.html, la solution ci-dessus doit être évitée. Utilisez plutôt ceci. La même solution est également fournie par Lopsided. Gardez-le ici pour permettre aux utilisateurs d'éviter d'implémenter la première solution de travail.

<modules>
  <remove name="UrlRoutingModule-4.0" />
  <add name="UrlRoutingModule-4.0" type="System.Web.Routing.UrlRoutingModule" preCondition="" />
  <!-- any other modules you want to run in MVC e.g. FormsAuthentication, Roles etc. -->
</modules>

Fonctionne bien, mais ce n'est pas une très bonne solution. Il est préférable d'utiliser UrlRoutingModule (voir la réponse de Lopsided ci-dessous). britishdeveloper.co.uk/2010/06/…
Der_Meister

37

Si IIS est installé ou activé après ASP.NET, vous devrez enregistrer manuellement ASP.NET auprès d'IIS pour que votre application .NET fonctionne.

Pour Windows 7 et versions antérieures:

  1. Exécutez l'invite de commandes (cmd.exe) en tant qu'administrateur.
  2. Accédez à l'emplacement .NET Framework approprié. (par exemple C: \ Windows \ Microsoft.NET \ Framework64 \ v4.0.30319)
  3. Exécutez aspnet_regiis.exe -i

Pour Windows 8 et versions ultérieures:

  1. Dans le menu Démarrer, tapez "Activer ou désactiver les fonctionnalités de Windows" et sélectionnez le premier résultat.
  2. Développez Internet Information Services: World Wide Web Services: Fonctionnalités de développement d'applications et sélectionnez ASP.NET 4.5 (ou ASP.NET 3.5 si vous devez prendre en charge des projets sur .NET Framework 2.0-3.5).
  3. Cliquez sur OK.

2
J'ai migré d'IIS Express pour le développement vers IIS complet et c'est ce qui m'a permis de résoudre le problème. Merci!
Jim Brown

1
Similaire à @JimBrown ci-dessus; cela a fonctionné pour moi après la migration d'IIS express.
SolidRegardless

Cela a résolu le problème pour moi. Sur Windows 7, Visual Studio 2015 Ent, nouveau site Web MVC 5, est passé d'IIS Express à IIS complet.
Geoff Gunter le

26

Exécutez-vous l'application API Web dans un répertoire virtuel ou une application?

Par exemple: j'ai eu le même problème lorsque j'ai déplacé mon projet vers mon IIS local sous le site Web par défaut> SampleWebAPI. Je pense que cela est dû au changement de URLroutage comme suit:

Original: localhost:3092/api/values
déplacé: localhost/SampleWebAPI/api/values

Si vous déplacez le projet d'API Web vers son propre site Web fonctionnant sur un port différent, cela semble fonctionner.

Note supplémentaire: j'avais encore compliqué le problème en ajoutant apicomme alias d'une application sur mon site Web, ce qui a fait en sorte que l'efficacité URLsoit:

localhost:81/api/api/values - remarqué cela après avoir déplacé le site Web vers son propre site Web

Par conséquent, parce que je voulais maintenir une séparation entre mon site Web et le site de projet mvc global.asaxde l'API Web , j'ai changé les règles de routage pour l'API Web "DefaultAPI" de api/{controller}/{id}à {controller}/{id}et ASP.NET MVC Defaultde {controller}/{id}à info/{controller}/{id}.


3
hehehe ... Je l' avais appelé mon application en IIStant que apitrop. Cela a provoqué tout ce débogage par essais et erreurs pendant plus de 2 heures. Merci beaucoup d'avoir partagé votre expérience! Je l'ai renommé et je suis de retour aux affaires : D
Leniel Maccaferri

Merci - c'était mon problème! :)
Jen

Je ne sais pas pourquoi les appels d'API échouaient alors que j'avais hébergé mon projet sous un port 8080, le simple fait de le déplacer en tant que répertoire virtuel sous le site Web par défaut a fait l'affaire :)
Kiran

14

C'est la seule réponse qui a fonctionné pour moi ...

J'ai eu un problème similaire ... Il semblait que peu importe ce que je faisais, rien n'était redirigé et mon fichier global était simplement ignoré. J'ai sérieusement envisagé de mettre fin à tout cela avant de trouver cette réponse. J'espère que ce lien aide quelqu'un d'autre.


L'ajout de ce qui suit au fichier web.config a fonctionné pour moi:

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

La balise system.webServer était déjà là bien sûr, mais j'y ai ajouté la balise modules , puis la balise remove & add to modules.


Hit ce problème sur un serveur 2008 (pas R2), et c'était la seule solution qui a fonctionné pour moi. De plus, j'ai dû combiner cela avec le réglage du pool d'applications en mode «intégré».
Zoomzoom

11

Quelques points à vérifier:

  1. Assurez-vous que .NET Framework 4 est installé.
  2. Assurez-vous que la version 4 du .NET Framework est sélectionnée pour votre site Web et votre répertoire virtuel (le cas échéant).
  3. Assurez-vous que MVC est installé ou que les DLL appropriées sont dans votre répertoire bin.
  4. Il peut être nécessaire d'autoriser les extensions de service Web ASP.NET 4.0
  5. Placez l'application dans son propre pool d'applications.
  6. Assurez-vous que le répertoire dispose au moins des autorisations d'exécution "Scripts seulement".

J'ai 4 autres applications Web normales fonctionnant sur le même serveur IIS et elles utilisent toutes .net framework 4. Alors lequel de ces 4 points n'est pas nécessaire? quand j'ai publié mon application mvc, j'ai ajouté les dépendances déployables et ajouté ASP.NET MVC afin qu'il soit dans mon répertoire bin
Armand

@Armand On dirait que vous avez fait # 1. Le n ° 2 est toujours nécessaire. L'ajout de dépendances déployables, si vous l'avez fait comme décrit ici: haacked.com/archive/2011/05/25/bin-deploying-asp-net-mvc-3.aspx , devrait prendre en charge le n ° 3 ci-dessus. Le n ° 4 peut être nécessaire ou non, même si je n'ai pas les connaissances nécessaires pour vous dire quand cela est et n'est pas nécessaire.
Joe Schrag

9

J'avais un problème similaire. J'avais les bons paramètres dans mon fichier web.config mais j'exécutais le pool d'applications en mode classique plutôt qu'en mode intégré

capture d'écran


7

Ce problème peut également survenir pour les raisons suivantes

1.Dans le Web.Config

<system.webServer>
     <modules runAllManagedModulesForAllRequests="true" /> 
<system.webServer>

Assurez-vous que les éléments suivants sont disponibles dans le dossier bin sur le serveur sur lequel l'API Web est déployée

  • System.Net.Http

  • System.Net.Http.Formatting

  • System.Web.Http.WebHost

  • System.Web.Http

Ces assemblys ne seront pas copiés dans le dossier bin par défaut si la publication s'effectue via Visual Studio, car les packages d'API Web sont installés via Nuget sur l'ordinateur de développement. Si vous souhaitez que ces fichiers soient disponibles dans le cadre de la publication de Visual Studio, vous devez définir CopyLocal sur True pour ces assemblys.

Sadish Kumar.V


Ces DLL sont nécessaires si MVC n'est pas installé sur le serveur. Dans mon cas, je voyais une page vierge en essayant d'appeler les API. L'ajout de la DLL a fonctionné manuellement pour moi. Merci!!
Vipul bhojwani

Mon problème a été résolu après avoir ajouté System.Net.Http au dossier de publication principal, le mien était la solution Asp.net Core
mohas

6

Sur la base de cette réponse SO , je viens d' avoir à changer path="*."à path="*"la ajoutée ExtensionlessUrlHandler-Integrated-4.0dansconfiguration>system.WebServer>handlers monweb.config

Avant:

<add name="ExtensionlessUrlHandler-Integrated-4.0" path="*." verb="*" type="System.Web.Handlers.TransferRequestHandler" preCondition="integratedMode,runtimeVersionv4.0" />

Après:

<add name="ExtensionlessUrlHandler-Integrated-4.0" path="*" verb="*" type="System.Web.Handlers.TransferRequestHandler" preCondition="integratedMode,runtimeVersionv4.0" />

Merci beaucoup Greg, j'étais sur le point de me tuer à cause de ce chemin stupide = "*." mais maintenant, après avoir laissé tomber ce misérable point, tout fonctionne parfaitement bien! Merci beaucoup!
Junior Silva

5

J'ai également rencontré ce problème. J'ai résolu le problème en accédant aux pools d'applications> Nom du pool d'applications et j'ai changé le .NET Framework de la version v.2.0.50727 à v4.0.30319.


1
J'ai découvert cela moi aussi. Faire voter votre réponse car elle est facile à manquer Lorsque j'ai créé un site pour mon application, IIS a automatiquement créé un pool d'applications pour moi, défini sur .NET v2.0 !! Pourquoi, pourquoi, pourquoi ?? :)
Mike Taverne

3

J'ai dû désactiver l'option de publication de fichier «Précompiler lors de la publication».


Et où faites-vous cela?
vapcguy

1
C'est dans une boîte de dialogue qui apparaît lorsque vous cliquez avec le bouton droit sur le projet et sélectionnez Publier. Il ressemble à ceci
Pakman

3

Il existe un correctif officiel de Microsoft: http://support.microsoft.com/kb/980368

Je ne recommande fortement PAS d'utiliser <modules runAllManagedModulesForAllRequests = "true">. Cela conduit toutes les demandes (même .jpg, .css, .pdf, etc.) seront traitées par tous les modules HTTP enregistrés. Il y a deux moments négatifs: a) charge supplémentaire sur les ressources matérielles; b) des erreurs potentielles, car les modules http traiteront un nouveau type de contenu.


1
Merci donc beaucoup! J'ai essayé absolument tout le reste, et c'est la seule chose qui a résolu le problème.
Oran Dennison

Pareil ici, merci beaucoup d'avoir ajouté cette réponse! Était la solution à mon problème!
Octavio Garbarino

2

J'ai commencé à recevoir 404 réponses de l'API Web après avoir suivi un didacticiel Windows Azure qui m'a dit d'ajouter un fichier «WebRole.cs» à mon projet.

Après avoir supprimé "WebRole.cs" de mon projet, mes appels d'API Web ont recommencé à fonctionner.


Cela a fonctionné pour moi. J'ai migré une application Azure vers un déploiement de machine virtuelle et après avoir commenté le contenu de WebRole.cs, mes appels WebAPI ont recommencé à fonctionner.
Scott

J'ai dû passer une journée là-dessus! Commenter WebRole.cs a fonctionné - me demande pourquoi cependant
Igorek

2

Assurez-vous que le pool d'applications est en mode intégré
et ajoutez ce qui suit au fichier web.config:

<system.webServer>
    .....
    <modules runAllManagedModulesForAllRequests="true" />
    .....
</system.webServer>

2

Dans mon cas, le problème était simplement que j'essayais d'accéder au site à l'adresse

myserver.myintranet.com/mysite

Mais la liaison de site Web pour http dans IIS n'avait pas le nom d'hôte spécifié dans la liaison. Cela avait fonctionné avant et je ne sais pas comment cela a été époustouflé.

Une fois que j'ai mis myserver.myintranet.comle nom d'hôte, le 404 était parti.

Dans IIS Manager, vous accédez aux liaisons ... dans le volet Actions, puis modifiez la liaison http pour spécifier le nom d'hôte.


Même moi, je suis également confronté au même problème. et comme vous l'avez suggéré, j'ai vérifié le nom d'hôte dans la liaison http, et il a été mis à jour correctement uniquement. Mais mon problème persiste. Remarque: j'ai hébergé mon application API en tant qu'application enfant. Veuillez suggérer si quelqu'un a une idée à ce sujet. ex: "sample.example.com" est mon application principale et a créé une API sous ce domaine sous le nom "sample.example.com/myAPI/"
Krishna Mani


1

Eu le même problème, une réponse 404 pour les contrôleurs de l'API Web lorsqu'ils sont servis depuis l'IIS, mais tout a bien fonctionné à partir de VS2010. Aucune des solutions ci-dessus n'a fonctionné pour moi. Finalement, j'ai trouvé que le problème était que nous avons ajouté la prise en charge de WSE 3.0 pour l'application et que la DLL Microsoft.Web.Services3 était manquante dans le répertoire / bin de l'application. Bizarre, mais après avoir copié la dll, le mappage d'itinéraire a commencé à fonctionner.


1

Pour moi, le problème était que le site racine était configuré pour utiliser un pool d'applications .NET 2.0, et mon application dans ce site était .NET 4.5.

J'ai créé un nouveau site avec un pool d'applications .NET 4 et placé mon application à la racine de celui-ci - et cela a bien fonctionné.


1

J'ai aussi eu du mal avec ça. Mon problème précis était que j'avais un service Web ASMX qui, lorsque je saisissais un paramètre dans une méthode Web et que je le testais, me donnait le 404. La méthode particulière avait bien fonctionné dans le passé et n'avait pas été modifiée, seulement republié. Ensuite, je suis arrivé ici et j'ai essayé toutes les réponses publiées et rien n'a aidé.

Ma solution ultime? Je sais que c'est drastique, mais je viens de créer une nouvelle solution Visual Studio et un nouveau projet Web. MVC sélectionné, puis j'ai fait un "Ajouter"> "Nouvel élément", sélectionné "Visual C #"> "Web" et "Service Web (ASMX)" en dessous. J'ai copié tout mon ancien code code-behind, puis j'ai pris note de l'espace de noms qu'il a donné au nouveau fichier dans mon nouveau projet, puis j'ai collé tout mon ancien code dans le nouveau fichier code-behind du nouveau projet et mis l'espace de noms retour à ce qu'il avait été.

Ensuite, j'ai créé mes dossiers dans mon projet que j'avais avant d'utiliser Visual Studio pour faire "Ajouter"> "Nouveau dossier", puis j'ai recopié mes fichiers dans les dossiers de mon autre projet à l'aide de l'Explorateur Windows, puis j'ai fait un clic droit sur chaque dossier dans Visual Studio et fait "Ajouter"> "Élément existant ..." et extrait les éléments de ces dossiers dans les dossiers Visual Studio de mon nouveau projet. J'ai de nouveau référencé tous mes assemblys .NET, en ouvrant les deux projets afin de pouvoir comparer ceux que j'avais référencés auparavant (il y en avait plusieurs). J'ai dû nommer mon nouveau projet légèrement différent - en gros, j'ai fait quelque chose de comparable à "GeneralWebApp" au lieu de "MyWebApp", par exemple - donc j'ai dû faire un "Replace All" dans toute ma solution pour remplacer ce nom,

Ensuite, j'ai fait un "Rebuild All" sur le projet, puis je l'ai démarré avec le bouton "Play" que Visual Studio donne quand je l'ai construit correctement. Cela a bien fonctionné. Alors je l'ai publié, et tout allait bien sur le serveur où je l'ai publié, quand je l'ai lancé à partir de là. Je n'ai aucune explication sur ce qui s'est passé, mais c'est ainsi que je m'en suis sorti. Ce n'est pas un mauvais test juste pour voir si quelque chose que Visual Studio fait a tout gâché.


1

Si vous placez uniquement le dossier bin dans IIS (après la création du projet), ce problème se produira également. Dans cette situation, vous devez publier le projet à l'aide de VisualStudio, puis placer le dossier publié dans IIS.


0

Quel type de requête HTTP faites-vous?

Ceci est une réponse légèrement à gauche, mais avez-vous essayé de supprimer la page d'erreur par défaut IIS pour 404 pour vérifier ce que votre API renvoie réellement?

J'ai eu un problème dans lequel je voulais une méthode de contrôleur pour renvoyer un 404 lorsque je POSTÉ le mauvais identifiant. J'ai constaté que j'obtenais toujours la page IIS 404 «Fichier ou répertoire non trouvé» plutôt que la réponse HTTP de mon API. La suppression de la page d'erreur 404 par défaut a résolu le problème.

Problème différent mais vous ne savez jamais que cela peut aider;)


0

Ce morceau de configuration dans le fichier web.config peut m'aider comme aidé: dans la section system.webServer:

      <security>
          <requestFiltering>
              <verbs applyToWebDAV="true">
                  <remove verb="PUT" />
                  <add verb="PUT" allowed="true" />
                  <remove verb="DELETE" />
                  <add verb="DELETE" allowed="true" />
                  <remove verb="PATCH" />
                  <add verb="PATCH" allowed="true" />
              </verbs>
          </requestFiltering>
      </security>      

0

J'ai récemment eu une erreur 404 non trouvée avec toutes mes routes / contrôleurs Web Api 2. Je suis donc allé sur le serveur réel et j'ai essayé de naviguer en utilisant localhost au lieu du nom d'hôte et j'ai obtenu "404.7 Not Found - Le module de filtrage des demandes est configuré pour refuser l'extension de fichier".

Ce message SO m'aide à le résoudre.


0

Cela a été résolu pour moi, lorsque j'active la case à cocher pour UrlRoutingModule-4.0:

IIS Manager> Modules> sélectionnez UrlRoutingModule-4.0> Edit Module> cochez la case "Invoke only for requests to ASP.NET applications or managed handlers".


0

J'ai eu le même problème: sur une machine nouvellement installée avec Visual Studio 2013, le projet d'API Web fonctionnait sous IISExpress, mais pas sous IIS local. J'ai essayé tout ce que j'ai pu trouver, mais au final le problème n'était pas nécessaire avec l'API Web, mais avec MVC: même s'il était installé, aucun projet MVC n'était en cours d'exécution.

Ce qui a fonctionné pour moi était de désinstaller IIS (à partir des fonctionnalités ADD / REMOVE Windows), puis de le réinstaller, puis d'exécuter aspnet_regiis -i. Peut-être que cela aide quelqu'un d'autre.


0

J'ai passé beaucoup de temps à essayer beaucoup de choses pour finalement réaliser que j'ajoutais mon application Web non pas dans Sites / Sites Web par défaut, mais dans un autre site Web lié à un autre port. Évidemment, essayer localhost sur le port 80 donnerait un 404.


0

je ne fais rien, ajoutez simplement cette balise dans web.config, son fonctionnement ce problème soulève l'un des points suivants

  1. Utiliser Web Api dans le même projet à l'aide de formulaires MVC ou asp.net

  2. Utilisez RouteConfig et WebApiConfig dans Global.asax comme GlobalConfiguration.Configure (WebApiConfig.Register); RouteConfig.RegisterRoutes (RouteTable.Routes);

  3. Utilisez RouteConfig à deux fins, les formulaires asp.net en utilisant le routage friendlyurl et mvc pour le routage MVC

nous utilisons simplement cette balise dans web.config, cela fonctionnera.

<system.webServer>
<modules runAllManagedModulesForAllRequests="true">
   .........................
</modules>
</system.webServer>

0

Ran dans le même problème avec l'API Web et l'API Web .Net Core. A bien fonctionné dans VS 2017 lors du débogage, mais a renvoyé 404 lors de la publication dans IIS 7.5. La solution pour moi était de changer la façon dont j'ai créé le site. Au lieu de publier à la racine d'un site Web (créé par un clic droit sur Sites ... Ajouter un site Web), j'ai dû créer une application (créée en cliquant avec le bouton droit sur un site Web ... Ajouter une application) et publier dans ce dossier. Notez que pour la version Core, j'ai dû changer le paramètre Version du pool d'applications .NET Framework sur "No Managed Code".


0

Pour moi, la solution consistait à supprimer les lignes suivantes de mon fichier web.config:

<dependentAssembly>
    <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-4.1.1.3" newVersion="4.1.1.3" />
</dependentAssembly>
<dependentAssembly>
    <assemblyIdentity name="Microsoft.IdentityModel.Tokens" publicKeyToken="31bf3856ad364e35" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-5.5.0.0" newVersion="5.5.0.0" />
</dependentAssembly>

J'ai remarqué que VS les avait ajoutés automatiquement, je ne sais pas pourquoi


0

Essayez cette webconfg .. remplacez "NewsApi.dll" par votre dll principale!


<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <location path="." inheritInChildApplications="false">
    <system.webServer>
      <handlers>
        <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule" resourceType="Unspecified" />
      </handlers>
      <aspNetCore processPath="dotnet" arguments=".\NewsApi.dll" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" />
    </system.webServer>
  </location>
</configuration>
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.