Can I use OData client code inside a Portable Class Library?

Question

I'm trying to build a portable class library targeting .NET, Silverlight, Windows RT and Windows Phone that acts as an OData client. I'm using Visual Studio 2012.

When I created the service reference to my OData server side, I got the following error message:

Unable to add a service reference to the specified OData feed because WCF Data Services is not installed for this target framework. To install a supported version of WCF Data Services, see http://go.microsoft.com/fwlink/?LinkId=253653.

When I go to the URL listed in the error message, I can choose between a library for Windows RT and one for Windows Phone, so this does not seem to work for a portable class library.

Is there any secret workaround to this, or do I have to code my own Odata client with bare HTTP requests?

Also, if I do have to use bare HTTP Requests, is there at least some kind of API I can build on for JSON or XML serialization / deserialization that works inside a portable class library?

Daukas

The source code to ODataLib (and WCF Data Services Client) is on odata.codeplex.com. That needs to be ported to a portable library. – Gramnegative

@Daniel: Thanks, but I knew this this already. – Daukas

No problem, it wasn't clear from the bounty description. I tried to drum up some interest: twitter.com/dsplaisted/status/278612579163725824 – Gramnegative

Answer 1

Actually I have a portable class library for OData (Simple.OData.Client) but didn't make a NuGet package for it yet. It's a part of Simple.Data OData adapter.

I am using Simple.OData.Client PCL in the app that I plan to port to various platform including iOS and Android (using Xamarin). If you are interested to give it a try I propose one of two alternatives:

a) Clone the Simple.Data.OData repo (https://github.com/simplefx/Simple.OData), switch to "winrt" branch, build it, there you have Simple.OData.Client that is a PCL supporting most of the platforms. Wiki currently describes Simple.Data adapter syntax, so you need to check Simple.OData.Client tests (https://github.com/simplefx/Simple.OData/tree/master/Simple.OData.Client.Tests) to understand the syntax. It has supports two syntax flavors: when you format filter string yourself and when you use its fluent API. Both of them are very straightforward to use.

b) I can speed up work on a NuGet package for a PCL (currently uploaded NuGet package only supports NET4), but it will take longer time.

Let me know if you are interested.

Ladon

Wow, this sounds exactly like what I was looking for - Thanks a lot! I'm currently working on another urgent project, but I definitely interested and I will take a look a bit later and get back to you then. – Daukas

After a first look at your docs I am impressed. Exemplary documentation and it seems like a very mature library. I'm sure this will be very useful. Thanks again and talk to you later! – Daukas

Good to hear it looks useful. I am deliberately waiting to release PCL version of the library so I can gather more feedback. For example just last Friday somebody asked to implement support NTLM authentication, so the new version is coming soon. My plan was to publish PCL once Mark Rendle releases 1.0 version of his Simple.Data lib, but as I said I can speed it up. – Ladon

For my authentication needs it's only important that I can inject HTTP Request headers as it is possible with the regular odata client. Is this possible with your library? – Daukas

I uploaded today version 0.10 that has support for both Basic and Windows authentication. It will take care of injecting headers. – Ladon

This is an example for Simple.Data OData adapter. Works similar for Simple.OData.Client (that is a portable part): github.com/simplefx/Simple.OData/wiki/Request-authentication – Ladon

That's great! Http headers are used in our public app for all kinds of things such as displaying the app name or requesting different access rights for a particular request. Thanks for the link, I'll have a look when I am back home. – Daukas

The newest version has support for request/response interception, so you can simply specify a delegate on HttpWebRequest that will be called prior the HTTP request execution. – Ladon

Actually managing headers with request interception will be the only way to pass credentials in a portable version of the library, since CredentialCache is not supported by all platforms. But I guess it will be OK for you since you are already using HTTP headers directly. – Ladon

Hi again, Now the wait is over, and Simple.OData.Client PCL has been uploaded to NuGet. Supports all platforms that you need. And it has now its own GitHub repo (forked from Simple.Data.OData) with Wiki and lots of examples. – Ladon

Thank you so much! This makes my efforts even easier. I really burning to start developing this client right away, too bad I still have to finish up another project first. – Daukas

I just awarded your post with a bounty as a small recognition to this outstanding library. Thanks again! :-) – Daukas

Wow! I don't think I'm worth that many points :) thanks a lot! – Ladon

Answer 2

The WCF DS Client library itself is not part of Portable Class Library so this is not expected to work (as you've found out). It uses ODataLib - Microsoft.Data.OData.dll which was not tested as part of portable class library, but that one should work.

So if you're OK using unsupported solution then feel free to use it. It is effectively the reader/writer for the OData format (ATOM/JSON, ...). Its source code is also available on codeplex, so if something doesn't really work in portable class library context, you could fix it (and please let us know).

In any case this library was designed to be as close to identical across all the platforms as possible, so the goal definitely is for it be part of the portable class library set, it just didn't get there yet.

Kummerbund

Thanks for your reply. I'm definitely ok with using odatalib, but I'm still a bit confused: I can't compile a portable library with odatalib included if you have different code bases for different platforms such as WinRT and Windows Phone. So, if I understand your suggestion correctly, then I should take whatever can be compiled in a portable class library from the odata lib and wrap the rest in a generic interface, then implement the missing rest in non-portable libraries for each system? – Daukas

I'm not sure exactly how Portable Libraries work in VS, but the general idea is that it's basically just a subset of the .NET API which can be used consistently on all platforms. Then you compile a dll against such API and it runs on all the platforms against the platform specific implementation of such API. So for ODataLib this can mean two different things: – Kummerbund

Either you "have" ODataLib on the target platforms and you want to write the code against it once. This should work today.. the API for ODataLib was specifically designed to NOT be platform dependent. The only exception is the Task based async APIS. So if you don't call those the rest looks exactly the same on all the platforms and thus should work everywhere. So what it would mean that you write your code once, compile it once and then distribute that dll for each platform along with the platform specific ODataLib dll (which is what is available on NuGet). – Kummerbund

The second possibility is to actually make ODataLib itself be a portable library and thus you could in theory use one build of ODataLib and distribute it on all the platforms. This is what didn't happen yet, but technically there are no things which limit this (obviously the Task based APIs would have to be left out, but they already are on the Phone version for example). You can either build this from the sources, or you can try if the phone binary would work on all the other platforms - not sure, totally unsupported :-) – Kummerbund

Vitek, thanks again for your detailed replies. I've already upvoted your answer, but will leave this open so I can put a bounty on this topic in case someone else has already done something similar and finds this thread. No need to re-invent the wheel :). In any case, I'll try to keep you updated on this. – Daukas