I created a WebAPI2 OData provider following Mike Wasson's tutorial found here. I then created a F# project to use the type providers to consume the service following the tutorial found here. The problem is that I am getting this exception when creating the Type Provider:
Error 1 The type provider 'Microsoft.FSharp.Data.TypeProviders.DesignTime.DataProviders' reported an error: error 7001: The element 'DataService' has an attribute 'DataServiceVersion' with an unrecognized version '3.0'.
Apparently, the most recent F# type providers do not support OData version 3. Is there a way that I can alter my OData service to return OData2 so that I can use the current F# type providers? Ideally, the F# type providers will support OData3 soon...
What are you using to host the OData service - WebAPI or WCF Data Services? If the former, there doesn't seem to be much support to gracefully fall back to V2. With WCF Data Services you can change the MaxVersion (the template DataService has the code in it) to V2 - I -believe- that this should do the trick.
Related
I created a .net 6 minimal API project with EF Core that uses DI to create repositories with Scoped lifetime. The API project uses mediatr to send the request to a proper handler. The handler's get injected with db repositories. This works when I run this project directly.
I am migrating that project to an AWS Lambda project using the new AWS .NET 6 Templates in the visual studio toolkit. For whatever reason, the exact same code that runs fine in the minimal API project now throws an error because the injected repositories dispose their connections before the end of the request.
This error occurs anytime I run a command against the database.
I believe this is happening because of a serialization error that occurs in entity framework core. This issue doesn't occur in my regular project because I'm guessing it's using a different serializer to handle the serialization of entities.
The errors being thrown are:
System.Text.Json.JsonException: A possible object cycle was detected. This can either be due to a cycle or if the object depth is larger than the maximum allowed depth of 32. Consider using ReferenceHandler.Preserve on JsonSerializerOptions to support cycles.
Cannot access a disposed context instance
If I update the Json Serializer that .net is using to handle cycles, then the 1st error turns into: "System.NotSupportedException: Serialization and deserialization of 'System.Type' instances are not supported".
This looks like some sort of conflict with Pomelo Entity Framework Core
and the way the .net 6 lambda templated project is setup.
EDIT:
After looking at this more, I think the issue is with whatever serialization library that AWS Lambda template project uses vs whatever serialization library is normally used by Pomelo to handle things.
I am creating OData endpoints using ASP.NET Web API using v5.8.0 of this NuGet package. I have everything working and I can retrieve simple data such as strings and ints without an issue. However I would now like to extend one of the endpoints so that one of the items that can be retrieved is a binary image file. Having read up on OData I have decided to use named resource streams to achieve this.
The problem I have is that I can find very little information on how to implement this using the ODataController. The closest I can find is this blog post but it is using an older version of Web API and the code does not compile when I use it in my project.
So can somebody please supply a working example of how this should be implemented please.
Named streams (aka stream properties) are not currently supported in Web API OData (for OData v4). See the following issues:
Clarify the situation for streams
Document for Stream Support in OData V4
Adding new entity to database via web api OData service keeps giving me the following error.
"Cannot convert a primitive value to the expected type 'Edm.DateTime'. See the inner exception for more details." I googled a bit and found out that it's related to OData not supporting DateTime type. I am using EF with database first approach and some of the entities have properties which are of DateTime Type.
Any suggestion for the issue?
Thanks.
Nyi
We currently have two different applications consuming our OData, WCF Data Service
We want to add a third application, but this one, rather than being a website, is another WCF Data Service. It is effectively a subset of functionality, exposing some methods from the internal service to as a public api.
As soon as I add a reference from one WCF Data Service to another, I end up in a conflict between System.Data.Services in the GAC and Microsoft.Data.Services implementations of DataService.
Is there a proper way to create an OData WCF Data Service wrapper for another OData WCF Service?
This is the error
Error 1 Reference.datasvcmap: The type
'System.Data.Services.Client.DataServiceCollection`1' is ambiguous: it
could come from assembly 'D:\source...\bin\Microsoft.Data.Services.Client.DLL' or from
assembly 'C:\Windows\Microsoft.Net\assembly\GAC_MSIL\System.Data.Services.Client\v4.0_4.0.0.0__b77a5c561934e089\System.Data.Services.Client.dll'. Please specify the assembly explicitly in the type
name. App_WebReferences/WcfDataService/
Not sure it has to do with the wrapping (may just be a side-effect from the way you set it up in Visual Studio). Try removing the reference to System.Data.Services.Client.dll, I believe the OOB NuGet packages are favored.
I want to use OData in Web Api for few Action methods in a Controller. What is happening is that once i enable OData in Web Api, the error message format is getting changes for all error .
Is there any way to configure Odata only for specific controller/action routes.
Error Message before Enabling OData looks like:
{"Message":"User Name/Password are invalid ."}
Error Message after Enabling OData looks like:
{
"odata.error":{
"message":{
"lang":"en-US","value":"User Name/Password are invalid ."
}
}
}
I would like to configure OData to handle only specific controllers so that rest of the APIs have no impact of OData setting. Your help is appreciated.
One of the big changes we made between RC and RTM is that we've completely removed the EnableOData extension method. We realized that registering OData formatters globally was a bad idea because it impacts controllers regardless of whether they're meant to be OData controllers.
So, in our v1 release for OData and in our current nightly builds, we've added a new base class called ODataController. If you derive from ODataController (or EntitySetController), you will automatically get support for OData just for that controller. It shouldn't affect the rest of your controllers the way it does now. You should also use config.Routes.MapODataRoute instead of EnableOData.
You can install our latest nightly build using these instructions:
http://blogs.msdn.com/b/henrikn/archive/2012/06/01/using-nightly-asp-net-web-stack-nuget-packages-with-vs-2012-rc.aspx
It should be pretty stable at this point.