I took a quick look into this after reading the last blog post from @colinblair about the WCF support beeing a bit troublesome.
It seems that the portable OpenRiaServices.DomainServices.Client works quite well (but I had to reacreated the Project file since VS 2013 tries to upgrade the current to framework version 5.0 which causes it to fail to load since there is no portable library version called 5.0), but that getting the web Project to work would be a lot more trouble.
I've played around a bit and have a working proof of concept solution where I have a PCL library (which only reference the Client assembly), a silverlight client and a web Project.
In order to make make it work there were some minor Changes which had to be made to the code generation (which I did by hand):
Changes to PCL code:
</br>* don't generate WebContext class in portable library (it will be generated in the platform specific client, silverlight Project in this case)
</br>* don't generate DomainContext default constructor and constructors taking in a Uri in portable library (since WebDomainClient is not accessible)
</br>* don't seal generated DomainContext classes so we can derive from it
</br>* the service contract inside the DomainContext class can be skipped in portable library since it will sometimes use WebGet attributes
Changes to platform specific (silverlight) project (which reference the same web project):
</br>* For each DomainContext class create a derived class which implement the constructors which was not exposed in PCL libray
</br>* Implement service contract in derived DomainContext classes
The major limitation here is that the PCL library can not create instances of the domaincontext class (since the two "normal" constructors dissapeared), but this can quite easily be solved by using a "factory" singleton defined in the PCL and set in platform specific project or maybe better by some quite simple reflection (add two "normal" constructors to DomainContext class and perform reflection to create correct WebDomainContext there).
Any thoughts about this approach to making a portable library?
Most of the work will happen in the code generation Tools which have to become PCL aware (right now codegen crashes for PCL libraries)
I am all for this Daniel, if you can figure out how to get a PCL version of the current WCF version then I would be quite happy.
I would be fine with dropping the WebContext from codegen completely, I have been creating my own instance of that class for years since I never RIA Link applications anyway. What I will do is go ahead and create a WebContext template and add it to the Visual Studio tooling.
I have a rebuilt version of the client Portable Class Library that Visual Studio doesn't try to reconvert every time you open it anymore. I will get that checked in later today.
Colin you don't have look at the WebContext, I had just copied the generated code from a Silverlight application and not a Silverlight library and since PCL libraries should be treated just as any library the WebContext will not be generated.
I've got the code-generator working for portable libraries now and I can verify that the webcontext is not generated.
I will look into making the code gen work for "desktop" .net applications and libraries also (which should hopefully be very simple now).
Once that is done you should be able to add a net40? build to all client packages (I have not tried to use the "Desktop" version of OpenRiaServices.DomainServices.Client and OpenRiaServices.DomainServices.Client.Web but I assume they should work just as the Silverlight versions).
Maybe we should add (preview?) client packages without "Silverlight" in the name which support both desktop and Silverlight and later add portable support into the same packages?
After that I will start making the generated code work in a portable libary, and I have a good idea of how to do so without requiring the final application to have a ria link (it just need to reference the assemblies).
Right now I think we can get a portable library (targeting just Silverlight + Desktop for the moment) without any api differences from the current version, but it will require a new assembly with the sole purpose of defining the few classes ([WebGet], [WebInvoke] and the interfaces which you removed from the current portable client ICollectionViewFactory?) and the which are otherwise not useable in PCL.
I have had a template for the WebContext on my old blog for years, removing it from code generation is something I have wanted done for years.
The desktop version of the client is the WPF version of RIA Services. As far as anybody knows, it has never actually been used to write an actual WPF application, they were originally used for unit tests because unit tests for Silverlight were not available when RIA Services was originally written. I would rather concentrate on a new portable version based on the Silverlight client than trying to use the desktop version.
For the portable version, my priority would be Silverlight + Desktop + WIndows 8 with a heavy emphasis on Windows 8.
Have you looked into how to create a windows 8 compatible version of the openriaservices.domainservices.client.web assembly?
I've have not worked with windows 8 apps at all, but it seems like the system.servicemode.web assembly is missing, which means that we have to implementation the used functionality in order to support win8. Based on a quick look it is the WebGetAttribute and WebHttpBehaviour which is used but missing (or are there any way to reference the full .net framework from an app?).
I have considered to create a portable assembly much as reactive extensions have their "System.Reactive.Interfaces" assembly which could provide declarations if the interfaces and classes (such as WebGetAttribute) not support in the current portable build. We could then provide platform specific versions of the assembly which would use the TypeForwardedTo assebly in order to use the actual implementation of the target platform. But I would still like to have an idea of how to target the win8 platform before I would add the system.servicemodel.web types to such an assembly.
My first ideas of how to remove the final dependencies to system.servicemodel.web from PCL libraries:
1; Don't use any references to WebGet in the code generation, but add [Invoke] and [Query] attributes instead.
Then we need to update WebDomainClientWebHttpBehavior to add the attributes at runtime (should be quite easy), but it does not solve provide us with an implementation for win8.
2; Add the WebGetAttribute to an rx-like "Interfaces" assembly, this would be even easier but would still require us to provide our own implementation of the WebHttpBehaviour for win8,
In either case I see no easy way to provide a win8 compatible client.web assembly without having to implement the used part of the WebHttpBehaviour (which hopefully is not a to large project) unless licences would allow us to either borrow code or at least take inspiration (look at the code) from the mono implementation of system.servicemodel.web. I've only had a quick look at the mono license and not the code itself, but the license seems quite permissive do you have
If we don't see a quick solution for win8 I will go ahead with support for PCL targeting all platforms (including win8), but only provide Silverlight and Desktop versions of openriaservices.domainservices.client.web. That way people can start thinking about using the PCL functionality now and can use their PCL in win8 apps at a later stage.
A preview of portable class library support can now be found at http://openriaservices.codeplex.com/SourceControl/network/forks/danneesset/openriaservices?branch=portable.
There are some issues left to look into before I create a PL from it:
* New code generation only works for C# (need to fix VB)
* Only the standard code generation is updated to work with PCL, the TextTemplate (T4) codegen also needs to be updated.
* Using PCL needs some additional testing (I have only confirmed that it works in a small simple project with 1 entity and 2 invoke methods)
* Some code cleanup
Other issues which needs to be solved in the future:
* Desktop support: Currently the desktop builds seems adapted for using with tests, we should probably use PCL version for desktop but it needs some tweaking.
* Win 8 support
The preview is now updated with all features in place:
* Codegen should now work for VB
* TextTemplate (T4) codegen has been updated
I am planning to perform some more testing and determine if I should have the codegen produce the old output for silverlight Projects before submitting a PL, but expect one to arrive before the end of march.
Currently (the T4 version) requires the updated openriaservices.domainservices.client assembly to be used and both codegen versions requires and updated openriaservices.domainservices.client.web assembly.
Excellent progress, and very well timed. The official production release should be out soon and the new RIA Linker is not limited to Silverlight projects.
I have now been using the code in my pull request (http://openriaservices.codeplex.com/SourceControl/network/forks/danneesset/openriaservices/contribution/6502) for two weeks and I have not found any issues with it so I feel it is ready to be merged into the master.
Would you like to have a look at it first Colin or should I just go ahead and merge it myself?
I was holding off while I was dealing with getting the tooling released and any issues cleared up on that side. Since I expected more users, and therefore more issues, I decided not to complicate things.
Sure, go ahead and merge the changes. There will be a merge conflict on the TT files as I added a setting that stops generating machine specific lines into the generated code. It would probably help if you incorporate that change and regenerate the files before attempting to merge.