swagger-ui gibt nach der Bereitstellung 500 zurück

78

Die sofort einsatzbereite Konfiguration funktioniert auf meinem Computer einwandfrei, überhaupt keine Probleme.

Bei der Bereitstellung in unserer Testumgebung wird jedoch die folgende Meldung angezeigt

500: {"Nachricht": "Ein Fehler ist aufgetreten." } / api / swagger / docs / v1

Die Bereitstellung erfolgt zu default web site/api

Ich vermute, es hat etwas mit der baseUrl oder so etwas zu tun, aber ich habe keine Ahnung, wo ich anfangen soll.

Meine Routen funktionieren innerhalb des Projekts einwandfrei. Ich kann alle meine Webapi-Endpunkte aufrufen und sie reagieren korrekt.

Jede Hilfe wäre sehr dankbar

c# asp.net-web-api swagger-ui swashbuckle

— VisualBean
quelle

166

Beim Debuggen verwendete ich die Debug-Konfiguration (für die ich XmlComments generiert hatte: Eigenschaften -> Registerkarte "Erstellen" -> Ausgabe -> XML-Dokumentationsdatei)

Ich hatte dies für meine Release-Konfiguration nicht getan (duh ...) - jetzt funktioniert alles

— VisualBean
quelle

Ich hatte das gleiche Problem. Meine Bereitstellung erfolgt in Azure und ich habe immer noch das Problem. stackoverflow.com/questions/39406820/…

— user2128702

1

Mein Einsatz war auf Azure, aber ich habe die einfache Sache vergessen. Ändern Sie die Projekteigenschaften, um die XML-Datei auch für den Release-Modus zu erstellen!

— Karl Gjertsen

Wie soll das Verzeichnis sein?

— Zapnologica

@Zapnologica es kommt darauf an, wo sich die Dateien befinden, sagen Sie swagger config.

— VisualBean

Es hat bei mir funktioniert, aber jetzt erscheint genau der gleiche Fehler in ALLEN Antwortkörpern aller Methoden. "Nachricht": "Ein Fehler ist aufgetreten." Wo soll ich jetzt suchen? Danke

— Johannes Wentu

22

Vielen Dank, dass Sie @VisualBean.

Da es für mich nicht so offensichtlich war ... wie man ... ein einfaches Bild macht.

In Projekt> Ihre Projekteigenschaften> Registerkarte Erstellen

— stefmex
quelle

10

Swashbuckle verbirgt die echte Fehlermeldung aufgrund Ihrer customErrors-Einstellung in web.config. Wenn Sie customErrors deaktivieren, sollte eine bessere Fehlermeldung angezeigt werden.

<system.web>
    <customErrors mode="Off"/>
</system.web>

— Fodonnel
quelle

Wenn die erste Antwort bei Ihnen nicht funktioniert. Verwenden Sie diesen Vorschlag (aktivieren Sie den benutzerdefinierten Fehlermodus), um zu sehen, was in Ihrem Programm vor sich geht. Mir wurde klar, dass jemand einen mehrdeutigen Endpunkt in einen unserer API-Controller eingeführt hatte. In dem Moment, als ich das korrigierte, ging es uns allen gut.

— Seun S. Lawal

3

Wie in der akzeptierten Antwort angegeben, müssen Sie sicherstellen, dass sich die Ausgabe der XML-Dokumentationsdatei in bin und nicht in bin \ Debug oder bin \ Release befindet (überprüfen Sie dies für alle Build-Konfigurationen).

Ich habe immer noch die 500-Antwort erhalten, da ich mehrere XML-Dokumentationsdateien verwende. In meiner SwaggerConfig- Implementierung füge ich XML-Dokumentationsdateien aus zwei Projekten hinzu (dem WebApi-Projekt selbst und einer Klassenbibliothek, auf die das WebApi-Projekt verweist):

c.IncludeXmlComments(string.Format(@"{0}\bin\MyWebApiProject.xml", System.AppDomain.CurrentDomain.BaseDirectory));
c.IncludeXmlComments(string.Format(@"{0}\bin\ReferencedProject.xml", System.AppDomain.CurrentDomain.BaseDirectory));

Die XML-Dokumentationsdatei des WebApi-Projekts wurde korrekt im bin-Ordner der Site veröffentlicht, die XML-Dokumentationsdatei des referenzierten Projekts jedoch nicht (obwohl sie im bin-Ordner des kompilierten Projekts angezeigt wird ).

Sie müssen also die WebApi-Projektdatei (.csproj) in einem Texteditor ändern und die folgenden Abschnitte unten hinzufügen ( ReferencedProject ersetzen ):

<PropertyGroup>
  <CopyAllFilesToSingleFolderForPackageDependsOn>
    CustomCollectFiles;
    $(CopyAllFilesToSingleFolderForPackageDependsOn);
  </CopyAllFilesToSingleFolderForPackageDependsOn>
  <CopyAllFilesToSingleFolderForMsdeployDependsOn>
    CustomCollectFiles;
    $(CopyAllFilesToSingleFolderForMsdeployDependsOn);
  </CopyAllFilesToSingleFolderForMsdeployDependsOn>
</PropertyGroup>
<Target Name="CustomCollectFiles">
  <ItemGroup>
    <_CustomFiles Include="..\ReferencedProject\bin\ReferencedProject.xml" />
    <FilesForPackagingFromProject Include="%(_CustomFiles.Identity)">
      <DestinationRelativePath>bin\%(Filename)%(Extension)</DestinationRelativePath>
    </FilesForPackagingFromProject>
  </ItemGroup>
</Target>

Siehe Wie fügen Sie zusätzliche Dateien mithilfe von VS2010-Webbereitstellungspaketen ein? für eine vollständige Erklärung.

— Sven Vranckx
quelle

Als Variante dazu habe ich das benutzerdefinierte Markup zur pubxml-Datei hinzugefügt und nicht csproj, wie im folgenden Link beschrieben. Wird auch verwendet Include=bin\*.xml, einschließlich der XML-Datei aus allen Projekten, auf die verwiesen wird, ohne dass diese explizit angegeben werden müssen. Siehe docs.microsoft.com/en-us/aspnet/web-forms/overview/deployment/…

— Joe

0

Das Problem ist, dass beim Ausführen dotnet publishmit -r Releasekeine XML-Datei erstellt wird. Allerdings erzeugt dotnet publishwith -r Debugtatsächlich die Datei. Dies erklärt, warum Benutzer dieses Problem nur erhalten, wenn sie in Umgebungen eingesetzt werden, die ANDERER als lokal sind, und sich dann selbst in die Knie zwingen, wenn die Ausnahme nur für Produkte gefunden wird Verzeichnis und Sie sollten das Problem sehen.

(UPDATE) Das Update für mich bestand darin, in die .csproj-Datei zu gehen und eine Zeile hinzuzufügen, um sicherzustellen, dass die Datei immer kopiert wurde. Diff unten gezeigt

— jbooker
quelle

1

Wenn Sie sich die akzeptierte Antwort ansehen, werden Sie wahrscheinlich sehen, warum dies so ist. :)

— VisualBean

@VisualBean Wenn Sie daraus schließen, dass die Lösung darin besteht, die csproj-Datei nach dem Ändern über das Eigenschaftenfenster zum Aktualisieren von Ausgabe> XML zu ändern, glaube ich nicht, dass die Lösung die Lösung für mich ist, und ich hatte das gleiche Problem. Stattdessen sind sowohl meine Debug- als auch meine Release-Konfiguration genau gleich und es ist nichts in der XML-Dokumentationsdatei angegeben. Der Debug-Build generiert diese Datei jedoch für das Debuggen und nicht für das Release.

— jbooker

1

Die akzeptierte Antwort besteht darin, XML-Kommentare in den Release-Einstellungen sowie in den Debug-Einstellungen zu aktivieren.

— Karl Gjertsen

@KarlGjertsen, mit "XML einschalten", was genau meinst du? Sie meinen, tatsächlich einen Wert in den "XML-Dokumentationspfad" einfügen? Da dies nicht die Lösung für mich war und ich nur wissen möchte, ob Sie konkrete Beweise dafür haben, dass dies die Lösung ist, sagen die Verse nur "die Lösung ist XYZ". Die Lösung für mich bestand darin, nur ein Dokument zur Quellcodeverwaltung hinzuzufügen, das abgeleitet wird, anstatt von msbuild abhängig zu sein, um dies für mich zu tun

— jbooker

Ich meine, das Kontrollkästchen in den Projekteinstellungen zu aktivieren, damit die XML-Kommentardatei automatisch generiert wird. Ich hatte dies für den Dubuffet-Build festgelegt, aber nicht für den Release-Build.

— Karl Gjertsen

0

Die akzeptierte Antwort sollte das erste sein, was Sie versuchen.

Ich habe jedoch meine XML-Ausgabe auf App_Data \ eingestellt und mein Swashbuckle so konfiguriert, dass es aus diesem Verzeichnis liest. Es spielt also keine Rolle, auf welche Weise es erstellt wird: Die XML-Dateien werden dort sein. Trotzdem bekam ich immer noch den Fehler ...

Ich fand in den MSDN-Foren die Antwort von @ many2012:

Wählen Sie "Zusätzliche Dateien am Zielort entfernen" in den "Dateiveröffentlichungsoptionen" im Bereich "Einstellungen" des Dialogfelds "Veröffentlichen".

Lief wie am Schnürchen!

— bkwdesign
quelle