[Discussion] Roadmap feedback

[Daniel-Svensson]

I've added a draft on future directions of the project at the wiki https://github.com/OpenRIAServices/OpenRiaServices/wiki/Vision---Roadmap

Any feedback can be posted here

[yowl]

Look into using EF.core for change tracking etc instead of current approach which mimics the "ObjectContext" approach popular in EF 4 and EF 5. Please only consider this if it doesn't stop other ORMs serverside. I use LLBLGen and would not want to have to switch.

[Daniel-Svensson]

@yowl thanks for the feedback.

The idea is to look into using ef core on the client side. As I see it there are 3 main options

1. Don't use it at all
2. Keep Enity base class and only use it internally under the covers (exchange current change tracking code)
3. Add option of a new kind of client context (I parallel to current model) with support for POCO classes

As for the server side the intention is to keep all currently supported ORM and possibly add new ones. I have now added ef.core server side support. (There is currently code for nhibernate and azure table storage but no supported nuget package).

[yowl]

@Daniel-Svensson Thanks for the clarification. That's fine with me. 2 would be the only one that would affect me but as its under the covers and removes some code in favour of reusing other tracking code that would seem to be a good idea in the interest of reducing maintenance. To put my cards on the table, I currently have LLBLGen with the old RIA/Silverlight. Their RIA provider is no longer maintained due to the decline in Silverlight but I am hoping medium/long term (within 18 months) to be able to move this over to wasm where I hope to also port across to OpenRia. Their RIA provider source is available so I should be able to get that working with OpenRia.

[yowl]

@Daniel-Svensson I would like to get a version that is netstandard2.0 compatible and that involves changing the client service proxy from Begin/End methods to a Task method (as svcutil does). Am i right in saying that the current codegen cannot do that? If I look here,

OpenRiaServices/OpenRiaServices.DomainServices.Tools/Framework/DomainServiceProxyGenerator.cs

Line 557 in 49a44c4

beginMethod.Name = "Begin" + operation.Name;

, it only seems to support Begin+End pattern.

[Daniel-Svensson]

@yowl yes, the current codegen only generates Begin/End method pairs and while the generated code is netstandard compatible the end platform's WCF implementation must support it as well as WCF REEST (which is not planned for netcore).

Also the current implementation relies on

Alternetives

1. Use the netstandard (not production tested) client I've been testing on several platforms
   It should be availible at https://github.com/Daniel-Svensson/OpenRiaPlayground/tree/master/HttpClient/OpenRiaServices.DomainServices.PortableWeb

but I just saw that my repository has gone, I have an OLDer backup at
https://svensson-daniel.visualstudio.com/_git/OpenRiaServicesPlayground/commits?itemPath=%2F&itemVersion=GBmaster

2. Update ria services to support Task

• Update codegen to generate both types of contracts (Begin/End) as we ll as a Task based implementation
• Make netstandard version of a DomainClient which calls this
  which calls this.
  This would probably required startign to use "Soap" endpoint instad (se example at https://svensson-daniel.visualstudio.com/_git/OpenRiaServicesPlayground?path=%2FHttpClient%2FWpfClient%2FSoapDomainClientFactory.cs&version=GBmaster
  )

As for netstandard support I have started some work with moving projects to vs2017 in order to be able to release a real netstandard 2.0 version of the client at https://github.com/Daniel-Svensson/OpenRiaServices/tree/feature/vs2017 but I dont have much spare time at the moment so work is progressing very slow

[Daniel-Svensson]

@yowl for you info, I've merged (but not published) netstandard2.0 support for client.
(#142)

It does still use Begin/End pairs so it will only run on platforms where that is supported (should include mono based platforms such as xamarin etc, but I am unsure if this would work with netcoreapp). Feel free to try it if you are intrested, I am considering trying to ship a preview within the next couple of weeks but could speed that up if requested.

[YZahringer]

+1 for Silverlight Support. I still have a lot of projects using Silverlight, waiting for their migration/refactoring to WPF or Xamarin.

This is an unofficial support of Silverlight projects in Visual Studio 2017/2019: https://marketplace.visualstudio.com/items?itemName=RamiAbughazaleh.SilverlightProjectSystem

[jeff-winn]

The long term goal for supporting ASP.NET Core is likely being held back by the hard dependencies on both WCF and FormsAuthentication. Even supporting something like ASP.NET Core running from the full .NET Framework may be a viable path forward.

I just wish it was already there, it’d be a big help when trying to migrate older projects off Silverlight since this toolset is primarily what’s holding my application back.

Don’t get me wrong I have loved RIA since 2010, but unfortunately times change. Thanks for all you’ve done!

[yowl]

For our part, we are looking at Uno. RIA was good for change tracking and validation on the client, but with .netstandard 2.0 supported via mono/wasm, we are using LLBLGen entities for that and have no need for Ria anymore. Its not all working yet, but it should be there within 18 months I think.

[Daniel-Svensson]

@jeff-winn thanks for the input.
But I dont understand why it is affects the move from silverlight.
The client compiles for the full framework as well as netstandard2.0 so it should not hold you back in modernising your client. If you want to minimize the effort I would suggest going to WPF since the frameworks are so similar most of the code will run without changes.

I've already had a look at separate hosting for netcore and the current dependencies are not that troublesome as one might think.

The core part of the server logic in the server assembly is netstandard2 compatible (see draft PR #151) and more is compatible with netcore 3.
The main issue is that "aspnet" authentication (FormsAuthentication) to be extracted to a separate assembly. But there is no hard dependency on FormsAuthentication (we been using asp.net Identity for a long time at work).

I've had some basic prof of concept running (without query support) and have a rough idea about what needs to be done, but there are a couple of different ways to go (build on top of mvc, directly as a middleware on global routing, use mvc odata or not ...) and the ecosystem does not seem ready to start too serious development yet. Since the announcement of "corewcf" (which should be very easy to start using) I am putting any such efforts on hold for a while in order to wait and se what happens.

There may however be some investment such as #159 to make DomainServices play better with aspnetcore based hosting.

If the framework has a future I think it is mostly for desktop apps (probably netcore), blazor client side apps (and maybe other frameworks such as uno) and mobile apps.

@yowl OpenRiaService client 4.6.0 is netstandard2.0 compatible.
If you have the time it would be great to know if it runs on uno

[jeff-winn]

@Daniel-Svensson Appreciate the response!

The class in question I'm referring to is this:
https://github.com/OpenRIAServices/OpenRiaServices/blob/master/OpenRiaServices.DomainServices.Server/Framework/ApplicationServices/AuthenticationBase.cs

That particular class uses both FormsAuthentication and Roles. Back when we started using RIA services when it first came out (2010ish if I recall) the usage of this particular class was in the stock template. I suppose if we had more expertise in the plumbing around this area it would be feasible to swap it out for something else, but unfortunately it just wasn't something we could take on ourselves without causing unnecessary risk to the security of the application.

We're using Identity on a number of other apps, the only ones we haven't managed to figure out how to upgrade were the early adopters of RIA services.

[Daniel-Svensson]

Important breaking changes (feedback wanted)

1. Changes in framework support

I am strongly considering dropping silverlight and portable class library targets in the next (breaking changes) release. This means that a 4.6.* branch will be created and where some changes might be contributed/backported.

Originally I had intended to keep the frameworks for the next release and then drop them and go on to make another breaking release without silverlight/PCL but I am currently thinking about trying to do everything in a single release instead.

If someone really feel like they need the changes for Silverlight and is willing to do the work required to setup Silverlight testing as part of the CI/CD pipeline and maybe some other releated work to validate the Silverlight builds I can reconsider sticking to my original plan.

2. Simplify Namespaces ?

I have been starting to considering simplifying the names and changing "OpenRiaServices.DomainServices" to just "OpenRiaServices" so that the assemblies and namespaces get shorter and better match the assembly names.
This would require "search and replace" work on upgrade, but would make it more intuitive and simpler to get started.

Any thoughts feedback about this?

[Daniel-Svensson]

@jeff-winn.
Yes the AuthenticationBase is a bit problematic since it is specific for the AspNet-membership identityt management despite it's name it is not a very good base class for other implementations.
If you want to use asp.net identity with openria I belive the easiest way is to create a domainservice which implements IAuthenticationService (or what it is called) otherwise you will need to override Login/Logout and possible the "GetUser" method(s?) and ensure that you don't call the base implementation.

[andrewhenry3]

I'm quite a few versions back, so this may have already changed, but: Is there an intent to keep a client to server communication protocol that is compatible with Silverlight RIA Service servers? As long as my WPF client can still communicate with the same server as the remaining Silverlight clients, then maintaining the Silverlight server in the 4.5 branch or even non-Open RIA Services and just using Open RIA 4.6 for new clients would be no problem.

…

On Fri, Jul 12, 2019 at 9:42 AM Daniel Svensson ***@***.***> wrote: *Important breaking changes* (feedback wanted) 1. Changes in framework support *I am strongly considering dropping silverlight and portable class library targets* in the next (breaking changes) release. This means that a 4.6.* branch will be created and where some changes might be contributed/backported. Originally I had intended to keep the frameworks for the next release and then drop them and go on to make another breaking release without silverlight/PCL but I am currently thinking about trying to do everything in a single release instead. If someone really feel like they need the changes for Silverlight and *is willing to do the work required* to setup Silverlight testing as part of the CI/CD pipeline and maybe some other releated work to validate the Silverlight builds I can reconsider sticking to my original plan. 2. Simplify Namespaces ? I have been starting to considering simplifying the names and changing "OpenRiaServices.DomainServices" to just "OpenRiaServices" so that the assemblies and namespaces get shorter and better match the assembly names. This would require "search and replace" work on upgrade, but would make it more intuitive and simpler to get started. Any thoughts feedback about this? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#127?email_source=notifications&email_token=AH3JTDFBHB6JY23G7YRLMI3P7CC3PA5CNFSM4FAYELA2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZZZH6Y#issuecomment-510891003>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AH3JTDDYIOMQHG24G3IRSS3P7CC3PANCNFSM4FAYELAQ> .

[Daniel-Svensson]

@andrewhenry3 you are correct, the 4.x (silverlight) clients should be able to support referencing and calling 5.+ servers.

So people should be able to continue to update the server libraries while staying on 4.6+ client libraries.

[jeff-winn]

@Daniel-Svensson Appreciate the tip. As for the roadmap question regarding Silverlight, if you're going to drop support for it the 5.x version would likely be your best candidate to do so. Microsoft won't be supporting it beyond 2021, and they have officially stopped supporting the development tooling as of Visual Studio 2015.

I would hate to see your long term roadmap hindered by trying to support a technology that already has one foot in the grave. So long as you can continue to do release patches against the 4.x versions, that should keep everyone happy if something needs to be patched for a security related problem. As soon as Microsoft stops supporting it, I'm expecting all the vendors we work with for various tooling to do the same (it's what I would do in their position).

Have a great weekend!

[Daniel-Svensson]

In the samples repository there is now a project using a netcore client and asp.net identity authentication (prof of concept, might need some further tweaking) @jeff-winn .

Currently a workaround is require for using netstandard/netcore clients (same would be required for uno @yowl)

[jeff-winn]

@Daniel-Svensson - thank you for that, it confirmed what I did once you mentioned that class could be replaced with identity. Glad to see there’s a sample how to do it now!

[Daniel-Svensson]

5.0.0-preview1 is now available on nuget.
Release notes are found at https://github.com/OpenRIAServices/OpenRiaServices/releases/tag/v5.0.0-preview1

Feedback and ideas for further features/fixes can be submitted to #178

[Daniel-Svensson]

5.0.0-preview2 is now availible on nuget.
The code generation now works with many other target frameworks including netstandard and netcoreapp. So it should now also work for Uno (@yowl)

Apart from that it contains several memory and performance improvements
Release notes are found at https://github.com/OpenRIAServices/OpenRiaServices/releases/tag/v5.0.0-preview2

[ehsangfl]

Hi
did you have any plan to support xamarin forms?
I know about netstandard code generator. but when i test it, it not works cause of xamarin forms 'ClientRuntime.ClientMessageInslectors' not supported

[Daniel-Svensson]

@ehsangfl I would like to support Xamarin.Forms but it is not something I will personally focus on for the foreseeable future. I would appreciate help with getting it working and setting up the unit tests to run for the platform as well.

As a workaround you might be able to set the CookieContainer to null on the DomainClientFactory or to create your own derived DomainClientFactory see CustomDomainClient in Samples reposotory or my HttpClient based factory which is linked from the roadmap

[ehsangfl]

thanks for your answer.
I try to implement for xamarin platform.
BR

[ehsangfl]

Hi daniel. I use HttpClient sample for xamarin project and it works fine and a minor change needed.
the change is in WebHttpQueryStringConverter class of hosting project

 public override object ConvertStringToValue(string parameter, Type parameterType)
        {
            if (parameter == null)
            {
                return null;
            }
            if (base.CanConvert(parameterType))
            {
                return base.ConvertStringToValue(parameter, parameterType);
            }

            parameter = HttpUtility.UrlDecode(parameter);
            using (MemoryStream ms = new MemoryStream(Encoding.UTF8.GetBytes(parameter)))
            {
                return new DataContractJsonSerializer(parameterType).ReadObject(ms);
            }
        }

Change to

 public override object ConvertStringToValue(string parameter, Type parameterType)
        {
            if (parameter == null)
            {
                return null;
            }
            //Ehsan Vali : Change on 18-03-1399
            if (parameterType.IsGenericType && parameterType.GetGenericTypeDefinition() == typeof(Nullable<>))
                parameterType = parameterType.GetGenericArguments().First();
            //================================
            //End of change

            if (base.CanConvert(parameterType))
            {
                return base.ConvertStringToValue(parameter, parameterType);
            }

            parameter = HttpUtility.UrlDecode(parameter);
            using (MemoryStream ms = new MemoryStream(Encoding.UTF8.GetBytes(parameter)))
            {
                return new DataContractJsonSerializer(parameterType).ReadObject(ms);
            }
        }

for deserialize nullable types of query string.

on xamarin forms client, the DomainClientFactory must set to

DomainContext.DomainClientFactory = new OpenRiaServices.DomainServices.Client.PortableWeb.WebApiDomainClientFactory()
           {
               HttpClientHandler = new System.Net.Http.HttpClientHandler()
               {
                   AutomaticDecompression = System.Net.DecompressionMethods.Deflate | System.Net.DecompressionMethods.GZip,
                   ServerCertificateCustomValidationCallback = (message, cert, chain, errors) => true,
               },
               ServerBaseUri = GetServerBaseUri(),
           };

and In System.ServiceModel.Dispatcher.QueryStringConverter on client pcl

 public static bool CanConvert(Type type)
        {
#if PORTABLE 
            switch (Type.GetTypeCode (type))
#else
            switch (Convert.GetTypeCode(type))
#endif
            {
                case TypeCode.Empty:
                case (TypeCode)2: // DBNull
                    return false;
                case TypeCode.Object:
                    if (type == typeof(TimeSpan))
                        return true;
                    if (type == typeof(DateTimeOffset))
                        return true;
                    if (type == typeof(Guid))
                        return true;
                    if (type == typeof(object))
                        return true;
                    if (typeof(IDictionary).IsAssignableFrom(type))
                        return true;
                    //				if (type.GetCustomAttributes (typeof (TypeConverterAttribute), true).Length > 0)
                    //					return true;
                    return false;
                default:
                    return true;
            }
        }

change to

 public static bool CanConvert(Type type)
        {
#if PORTABLE 
            switch (Type.GetTypeCode (type))
#else
            switch (Convert.GetTypeCode(type))
#endif
            {
                case TypeCode.Empty:
                case (TypeCode)2: // DBNull
                    return false;
                case TypeCode.Object:
                    if (type == typeof(TimeSpan))
                        return true;
                    if (type == typeof(DateTimeOffset))
                        return true;

                  //Ehsan Vali Change on 1399/03/18 
                    if (type == typeof(DateTime))
                        return true;
                    //================================

                    if (type == typeof(Guid))
                        return true;
                    if (type == typeof(object))
                        return true;
                    if (typeof(IDictionary).IsAssignableFrom(type))
                        return true;
                    //				if (type.GetCustomAttributes (typeof (TypeConverterAttribute), true).Length > 0)
                    //					return true;
                    return false;
                default:
                    return true;
            }
        }

I developed a project by xamarin forms and this is work like charm.
but I'm not test it on IOS.

I Mark changes form better understanding

Thx
BR

[ehsangfl]

the good news is that openriaservices work in blazor wasm.D:)))))

[Daniel-Svensson]

@ehsangfl good news. If you have the time a it would be awesome if you could submit a sample (or more) to https://github.com/OpenRIAServices/Samples as a PR

[dsoltesz]

Support Client Side Blazor

[ehsangfl]

do you have any plan to continue develop this framework?
today we have a lot of dotnet client technology,like Xamarin and blazor, and this framework is worked on both of Xamarin and blazor platform and is best solution for ria applications.
If you are going to continue developing, do you have any plan to use gRPC instead of WCF ?
BR