Question

使用这种技术（How to dynamic add filters to a LINQ query against an Odata Source in C#）我在我的Odata端点的LINQ查询中动态构建了一个where子句。我经常这样做，效果很好。但是现在我的查询包含一些odata v3.0功能，我收到了这个错误。

DataServiceVersion'1.0'对于请求来说太低了。支持的最低版本为“3.0”

我使用唯一的Northwind端点构建一个简单的再现，并且可以在标准C＃代码或linqpad中重现它。

Northwind Endpoint：http://services.odata.org/Northwind/Northwind.svc/

查询有效。

from x in Categories
where x.Products.Any( e => e.ProductName == "chai")
select x

查询生成的URL。

http://services.odata.org/Northwind/Northwind.svc/Categories()?$filter=Products/any(e:e/ProductName eq 'chai')

这是查询，如果我动态生成了where子句（就像我上面链接的技术那样）

 from x in Categories.AddQueryOption("$filter",  "Products/any(e:e/ProductName eq 'chai')")
 select x

但现在我收到了错误。

当我查看我的DataServiceContext时，它有一个表示V3的MaxProtocolVersion，当然我的项目是dotnet 4.5，并且普通查询正在运行。

所以我认为正在发生的事情是服务器支持V3功能，而我正在使用它，但是客户端必须查看LINQ查询并将其DataServiceVersion标识为在其中使用的功能的最小公分母。查询，因为我正在使用V3功能，但只是在它无法推理的动态部分，它认为我只使用V1功能..

如果我在选择中使用V2功能（投影），如下所示

from x in Categories.AddQueryOption("$filter",  "Products/any(e:e/ProductName eq 'chai')")
 select new { x.CategoryID, x.CategoryName }

然后我得到一个稍微不同的错误

DataServiceVersion'2.0'对于请求来说太低了。支持的最低版本是“3.0”。有关详细信息，请参阅下面的例外情况。

这似乎支持了我的假设..

所以我可以看到2个解决方案 1）告诉DataServiceContext或引擎FORCE客户端将查询识别为V3，或者像上面我在查询选择中使用了V2功能，从而提出引擎可以解决的“最小公分母”从它可以识别的查询部分，所以同样可以在Select中使用一些V3功能，或者只是强制查询实际上是V3的另一个子句？

有人知道任何有用的东西吗？

Answer 1

这是我发现的工作。基本上我只是挂钩并覆盖HTTP标头

MyDatacontext.SendingRequest2 += (sender, eventArgs) => {                 
           eventArgs.RequestMessage.SetHeader("DataServiceVersion", "3.0;NetFx");
    };

我正在使用WCF 5.0，因此正在使用SendingRequest2，但是如果使用旧版本，您可以使用折旧的SendingRequest或BuildingRequest事件。

DataServiceVersion冲突：DataServiceVersion'1.0'对于请求来说太低了。支持的最低版本是'3.0'

1 个答案: