我遇到了一个困扰了几天的奇怪问题。
我有一个项目，我在其中使用OData访问实体集，这些实体集是由Automapper从Entity Framework实体映射的DTO。所有这些都在ASP.NET Core Web API项目中。
我有一个引起问题的特定设置。
具有1：1子代的实体，其本身具有1：1子代，两种关系都是可选的。
我正在查询的实体集存在，但与其他两个实体没有空关系。
我使用OData的<object>进行查询。
这将导致空引用异常。
ASP.NET Core Web Server的完整输出位于此处-https://gist.github.com/nickspiers/3620840145d0a88e3966643613a5d442
最简单的形式是这里的问题-https://github.com/nickspiers/efcore-issue
我试图将所有内容简化为最简单的部分，但是如果我忘记了更多信息，请让我知道我还能提供什么。谢谢！
答案 0 :(得分：2)
是的，现在转到Odata和Entity Framework Core github网站，并感到震惊。
遗憾的是您无能为力。错误TOMS-EF Core在某些情况下几乎不可用。
官方的立场是，这很可能会在3.0的时间框架内固定下来-您很可能会在2019年夏季使用。不要开玩笑。在此之前，它们已经推迟了整个LINQ问题。2.1-不重要。 2.2-小版本，而不是辛苦的linq工作。祝您玩得开心。
在同一地点。
我在这里开始了关于它的讨论：
https://github.com/aspnet/EntityFrameworkCore/issues/12953
答案包括：
查询缺少测试范围。我们正在对此进行一些研究 前沿，但这不是一件小事，而且会占用资源 不能添加功能或修复错误-2.2较小的原因之一 发布。其中一部分将使人们更容易提交 测试。
和
很明显，使用OData会导致某些查询模式 比写查询的情况更普遍 用手。这使得它特别容易缺少测试范围。
OData WebApi对此也有未解决的问题。
目前唯一明智的解决方法可能是：
6.2可能很旧，可能“没有那么多花哨”-但它在LINQ端的错误更少，实际上可以在这种情况下使用。
这是核心问题，而不是OData问题-LINQ有效。这完全是EF Core产品问题，已在翻译/提供商站点上发布了与GLARING问题有关的问题，这些问题都没有得到任何妥善处理，但似乎积压了3.0
现在，在您的特定情况下-您执行ProjectTo，对吗？ TO你把里面的东西包括在内吗？ EF Core有其他问题。是的，不要开玩笑。但是在publich中有代码可以提取所需的Include，您可以使用它们。您肯定需要提取包含内容，然后在ProjectTo中使用它们。
我使用第二部分（检查是否存在某些构造）来检查是否直接返回IQUeryable，还是先执行ToList（这会导致内存处理效率低下，但是有些事情需要它）。