7

我有一个 ASP.NET WebAPI 项目，我试图用 Swagger UI 替换我们旧的 XmlDocumentationProvider 页面。我正在为 webAPI 5.3.1 nuget 包使用 swashbuckle swagger。

我能够导航到 localhost/MyApp/swagger，我可以在 fiddler 中看到它调用 localhost/MyApp/swagger/docs/v1 来检索代表我的 API 的 JSON 字符串。调用成功，JSON大约240KB，JSON有效。此时，chrome 选项卡会冻结大约 30 秒，然后会因“Aw snap”页面而崩溃。控制台中没有错误。

尝试在此在线验证器中验证 api JSON有效，并且仅当我取消选中所有三个“Follow ___ $refs”复选框时，规范/模式才有效。如果选中其中任何一个框，则大约需要 30 秒，然后该工具会崩溃。

不幸的是，我无法将整个 webAPI 规范粘贴到某个地方，但我会说它适用于非常庞大且非常复杂的内部业务应用程序。我们的一些 DTO 具有循环引用（与 DTO 本身类型相同的属性），我怀疑这可能会导致问题，但没有任何日志记录或调试我无法确定，并且有超过 1000 个 DTO 类我不想梳理它们以检查。

有没有办法为 swashbuckle（在服务器上）或 swagger UI（在客户端）打开任何类型的日志记录或调试？有没有人遇到过浏览器崩溃的问题并知道是什么原因造成的？提前谢谢。

4

7 回答 7

15

我能够注释掉我的每个 API 控制器，加载 swagger 页面，然后重新打开它们，直到页面再次崩溃。一旦我弄清楚哪个控制器是问题所在，我对控制器中的所有端点重复了这个过程。

事实证明，我们非常古老的方法之一是将 ORM 实体作为主体参数（非常糟糕），这导致 swagger 尝试解析我们的整个 ORM 对象图并耗尽内存。更改此方法以接受 DTO 而不是数据层实体解决了该问题。

于 2016-02-25T19:44:26.000 回答
3

我认为这是一个已知错误，当​​您使用非标准序列化程序或 Web api 配置非标准时。

这是一个循环引用问题。

在 git hub 存储库中查看问题： https ://github.com/domaindrivendev/Swashbuckle/issues/486

于 2016-02-26T13:07:26.880 回答
1

如果其他人遇到这个问题并且似乎没有任何帮助，这就是我在我们的代码中发现的。

我们有一个人签约编写我们的 API，他一定是自动导入了一堆基于 DB Schema 的类，但它所做的是创建了大量引用其他部分类的部分类，而这些类又引用了回来到原来的班级。

因此，如上所述，这最终成为一个循环引用问题，但并不完全相同。我花了一段时间才弄清楚有什么不同，但是当我注释掉对其他部分类的引用时，一切都很好。

我的建议是结合上述 2 个答案，使用您自己的 DTO 并确保您没有循环引用。

另一个重要的问题是在我们的[Route()]标签中，这家伙[Route("{model}"]在 POST/PUT 方法的参数中放入了标签，他正在使用[Route("{model}")]标签来解析模型的 JSON 主体，因此将它放在 Route 标签中是不必要的，并导致问题。它应该只是[Route("")]。

于 2019-02-15T15:34:05.643 回答
0

检查您ResponseType的 api 方法的属性。就我而言，当我修改 api 方法时，我忘记删除响应类型，因为我删除了返回对象。

于 2020-08-13T09:27:06.147 回答
0

我遇到过同样的问题。最后，我可以[ResponseType()]按照自己的意愿保留 ORM 实体，但我设法通过在其中添加另一个模型来使招摇不冻结[SwaggerResponse()]

以下是更多信息： https ://mattfrear.com/2015/04/21/generating-swagger-example-responses-with-swashbuckle/

于 2020-09-29T14:10:07.227 回答
0

我一直在试图找到 Swagger UI 产生此“页面无响应/您可以等待它变得响应或退出页面”的原因。对话框（与 Chrome 中显示的一样。）Chrome 偶尔会发出“Aw，Snap！错误代码：内存不足”。

[Edge 和 Firefox 的行为相似。]

如果我反复告诉浏览器等待，大约一两次，请求最终会成功。这显然是一个不确定的、间歇性的错误。因此，它不太可能是某种循环引用的结果。看起来 Swagger UI 只是使用了过多的内存，导致浏览器超时。

我的 Web API 已经增长到大约 55 个路由；但我怀疑问题可能源于底层实体框架 DbContext 的复杂性。Swashbuckle 似乎在其 Web API 模式生成期间对 DbContext 执行反射；但我不熟悉这实际上是如何工作的。

我第一次遇到这个问题是在 ASP.NET Core 3.1；但我目前的目标是 .NET 6 Preview 5。

我尽量保持包是最新的；目前有 Swashbuckle.AspNetCore 的版本 = 6.1.4。

我尝试从我的项目中排除 Web API 的每个子路径。这仅在我删除所有引用 DbContext 的路由时才开始起作用。

我还有其他基于更简单的 EF 数据模型的 Web API 项目，其中 Swagger UI 工作得很好。

于 2021-06-22T23:00:09.043 回答
0

我们有一个来自 NetTopologySuite.Geometries 命名空间的“Point”类，它使招摇撞毁。

于 2021-03-16T10:22:31.550 回答