v5.1.0-preview.1

[Daniel-Svensson]

• New HttpClient based DomainClient - BinaryHttpDomainClientFactory (Add HttpClient based DomainClient for cross platform binary transport  #290, #
• BREAKING CHANGE Changes to wire format in order to fix serialization of DateTime (nullable and on complex objects) (Change Uri serialization for nullable and complex types #289, nullable datetime parameter set to datetimekind.local #75)
  • 5.1 Clients need a 5.1 Server
  • Server is backwards compatible so that it can be upgraded safly first
• Potential BREAKING change: Complex Objects/Typs (classes/structs which are not entities) parameters will now always be validated (Validate complex objects for invoke #303,
  • Previously they were only validated when calling entity actions and not Invoke methods

BinaryHttpDomainClientFactory

Add a new cross platform (Including Blazor wasm) more easily extensible DomainClient for the binary protocol.

• Enable binary endpoint to be use on other clients than .Net Framework
• Adds support for blazor wasm where the wcf soap based client has problems
• Enable easier extensibility such as oath, client side caching, compression etc using standard HttpClient middleware (HttpMessageHandler)
• Can support HTTP2 and other more advanced networking features

HttpMessageHandler httpMessageHandler = new HttpClientHandler() { ... };
DomainContext.DomainClientFactory = new OpenRiaServices.Client.DomainClients.BinaryHttpDomainClientFactory(httpMessageHandler)
            {
                ServerBaseUri = "https://YOUR_SERVER_URI"
            };

Or if you want to use factory for your HttpClients you can pass in a function as callback

DomainContext.DomainClientFactory = new OpenRiaServices.Client.DomainClients.BinaryHttpDomainClientFactory(() => createHttpClient())
            {
                ServerBaseUri = "https://YOUR_SERVER_URI"
            };

---

This discussion was created from the release  v5.1.0-preview.1.

[Daniel-Svensson]

BinaryHttpDomainClientFactory feedback

• Should add "ServiceBaseUri" to constructor since it is mandatory Add ServiceBaseUri to BinaryHttpDomainClientFactory constructor #319
• Need to update fault handling (it does not currently handle the case where there is no exception detail) Make fault handling more tolerant to different variants of Faults #310
• Serialization of parameters to entityactions might behave a bit different BinaryHttpDomainClientFactory: Properly handle nullable parameters for EntityActions #311
• Properly handle derived types from parameters by always serializing as type on method BinaryHttpDomainClient: Serialize parameters based on contact's parameterType #318

Other changes for preview.2 ?

• Add net5 or netstandard build target for server project?

Changes before final release:

• Move to separate nuget package with same name as assembly

[Daniel-Svensson]

@ehsangfl @dsoltesz as I understand it you are currently using a version of the HttpDomainClient from the sample project.
I have updated the sample project to use the new BinaryHttpDomainClientFactory

We have been running the new BinaryHttpDomainClientFactory in our internal environment for a couple of days and it seems to work fine (except for handling of unexpected errors without exception details)

I would appreciate if you gave it a try and come with any feedback on it
The final names or API have not been nailed yet

[dsoltesz]

I’ll try updating my current project to use the new updated package and remove my custom RiaServices folder/code from my blazer wasm app

…

________________________________ From: Daniel Svensson ***@***.***> Sent: Thursday, September 30, 2021 3:38:01 AM To: OpenRIAServices/OpenRiaServices ***@***.***> Cc: dsoltesz ***@***.***>; Mention ***@***.***> Subject: Re: [OpenRIAServices/OpenRiaServices] v5.1.0-preview.1 (Discussion #309) @ehsangfl<https://github.com/ehsangfl> @dsoltesz<https://github.com/dsoltesz> as I understand it you are currently using a version of the HttpDomainClient from the sample project. I have updated the sample project to use the new BinaryHttpDomainClientFactory We have been running the new BinaryHttpDomainClientFactory in our internal environment for a couple of days and it seems to work fine (except for handling of unexpected errors without exception details) I would appreciate if you gave it a try and come with any feedback on it The final names or API have not been nailed yet — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#309 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AALFFSNRZI6LVNCUMYXWBKTUEQHVTANCNFSM5FBUA6VA>.

[dsoltesz]

I have things updated and working with the latest preview. I want to do some more testing around server errors and not authorized. Will keep you posted

…

________________________________ From: Dan Soltesz ***@***.***> Sent: Thursday, September 30, 2021 7:55:02 AM To: OpenRIAServices/OpenRiaServices ***@***.***>; OpenRIAServices/OpenRiaServices ***@***.***> Cc: Mention ***@***.***> Subject: Re: [OpenRIAServices/OpenRiaServices] v5.1.0-preview.1 (Discussion #309) I’ll try updating my current project to use the new updated package and remove my custom RiaServices folder/code from my blazer wasm app

________________________________ From: Daniel Svensson ***@***.***> Sent: Thursday, September 30, 2021 3:38:01 AM To: OpenRIAServices/OpenRiaServices ***@***.***> Cc: dsoltesz ***@***.***>; Mention ***@***.***> Subject: Re: [OpenRIAServices/OpenRiaServices] v5.1.0-preview.1 (Discussion #309) @ehsangfl<https://github.com/ehsangfl> @dsoltesz<https://github.com/dsoltesz> as I understand it you are currently using a version of the HttpDomainClient from the sample project. I have updated the sample project to use the new BinaryHttpDomainClientFactory We have been running the new BinaryHttpDomainClientFactory in our internal environment for a couple of days and it seems to work fine (except for handling of unexpected errors without exception details) I would appreciate if you gave it a try and come with any feedback on it The final names or API have not been nailed yet — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#309 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AALFFSNRZI6LVNCUMYXWBKTUEQHVTANCNFSM5FBUA6VA>.

[dsoltesz]

Things seem to be working good so far

…

________________________________ From: Dan Soltesz ***@***.***> Sent: Thursday, September 30, 2021 2:55:44 PM To: OpenRIAServices/OpenRiaServices ***@***.***>; OpenRIAServices/OpenRiaServices ***@***.***> Cc: Mention ***@***.***> Subject: Re: [OpenRIAServices/OpenRiaServices] v5.1.0-preview.1 (Discussion #309) I have things updated and working with the latest preview. I want to do some more testing around server errors and not authorized. Will keep you posted

________________________________ From: Dan Soltesz ***@***.***> Sent: Thursday, September 30, 2021 7:55:02 AM To: OpenRIAServices/OpenRiaServices ***@***.***>; OpenRIAServices/OpenRiaServices ***@***.***> Cc: Mention ***@***.***> Subject: Re: [OpenRIAServices/OpenRiaServices] v5.1.0-preview.1 (Discussion #309) I’ll try updating my current project to use the new updated package and remove my custom RiaServices folder/code from my blazer wasm app

________________________________ From: Daniel Svensson ***@***.***> Sent: Thursday, September 30, 2021 3:38:01 AM To: OpenRIAServices/OpenRiaServices ***@***.***> Cc: dsoltesz ***@***.***>; Mention ***@***.***> Subject: Re: [OpenRIAServices/OpenRiaServices] v5.1.0-preview.1 (Discussion #309) @ehsangfl<https://github.com/ehsangfl> @dsoltesz<https://github.com/dsoltesz> as I understand it you are currently using a version of the HttpDomainClient from the sample project. I have updated the sample project to use the new BinaryHttpDomainClientFactory We have been running the new BinaryHttpDomainClientFactory in our internal environment for a couple of days and it seems to work fine (except for handling of unexpected errors without exception details) I would appreciate if you gave it a try and come with any feedback on it The final names or API have not been nailed yet — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#309 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AALFFSNRZI6LVNCUMYXWBKTUEQHVTANCNFSM5FBUA6VA>.

[dekenless]

So does 5.1 do away with WCF?

[Daniel-Svensson]

WCF is still there; there is just a new option/domainclient for the client to connect without WCF.

[dekenless]

Using the 5.1 preview but with a WPF client I am attempting to implement token authentication using OpenIdDict (I am doing a test using the sample WASM app as the basis). Everything works as I would expect with the UserController (the User is set to a ClaimsIdentity) when calling using a HttpClient and setting request.Headers.Authorization = new AuthenticationHeaderValue("Bearer", ""). However, if I make a call to a DomainService method I am not seeing the User set--it is always anonymous. (on the domainservice call, I implemented a HttpClientHandler and set the Authorization header in the overridden SendAsync method).

Any thoughts as to why it would worth with the ApiController but not the DomainService?

[Daniel-Svensson]

That sounds strange, I really dont know.
Maybe it has something to do with the DomainService running on top of WCF Rest while the the ApiControll beeing based om MVC?

I've used the owin middleware as well as handlers in the Asp.Net "global" begin/request authenticate etc with success earlier.

Some things to look into.

• Put breakpoint in asp.net's "BeginRequest" or use fiddler to inspect the request to double check that the requees-Headers are set as you expect
• Ensure that your openiddict authentication code is run before the domainservice methods (you might have to look at the dokumentation how to integrate with "ASp.Net webforms" or WCF Rest) ?
• I've previously had problems when trying to mix MVC/webapi with WCF/OpenRiaServices it seems the default templates contains some kind of catch/all handlig which prevents openriaservices from handling the requests at all

[dekenless]

I made some progress I think using the setting from the web.config in the WpfCore_AspNetIdentity sample. So, the Claims does appear now in the user context, but authenticating the token (or getting the correct context from the token is not occurring).

The OpenIdDict validation all happens after Application_PostAuthenticateRequest & Application_PostAuthorizeRequest and as I said does work on WebApi calls. I have verified the bearer token is correctly set on all calls.

What is interesting is if I call the Ria method directly with my own HttpClient it works, for example:

            using var request = new HttpRequestMessage(HttpMethod.Get, @"https://localhost:44373/Ria/Services/SimpleApplication-Web-SampleDomainService-SampleDomainService.svc/binary/GetQueryableRangeTask");
  request.Headers.Authorization = new AuthenticationHeaderValue("Bearer", _lastuser.AccessToken);
  using var response = await client.SendAsync(request);

This works as I would expect and the "[RequiresAuthentication]" works correctly with the User correctly set.

[dekenless]

The issue is resolved, when using OpenIdDict I needed to enable UseActiveAuthentication like so UseOwin().UseActiveAuthentication() which solved the issue.

[dekenless]

Before 5.1, I was able to execute a domain query on a thread other than the Dispatcher, while having bindings to the underlying Context entities. In 5.1, if I run the same code I get exceptions System.NotSupportedException: This type of CollectionView does not support changes to its SourceCollection from a thread different from the Dispatcher thread.

I am wonder was there a change in 5.1 as to how the results are added to the EntityCollection. I am not saying there is a bug in 5.1, but I am wondering why my code now fails. To that end, is there a mechanism I can use so when elements are added to the EntityCollection I can have some control (i.e. use the Dispatcher to do so to eliminate the exception).

This is the underlying exception:

OpenRiaServices.Client.DomainOperationException: Load operation failed for query 'GetSomeStuff'. This type of CollectionView does not support changes to its SourceCollection from a thread different from the Dispatcher thread. ---> System.NotSupportedException: This type of CollectionView does not support changes to its SourceCollection from a thread different from the Dispatcher thread. at System.Windows.Data.CollectionView.OnCollectionChanged(Object sender, NotifyCollectionChangedEventArgs args) at OpenRiaServices.Client.EntityCollection``1.ListCollectionViewProxy``1.OpenRiaServices.Client.ICollectionChangedListener.OnCollectionChanged(Object sender, NotifyCollectionChangedEventArgs e) at OpenRiaServices.Client.EntityCollection``1.RaiseCollectionChangedNotification(NotifyCollectionChangedAction action, IList entities, Int32 startingIndex) at System.Collections.Specialized.NotifyCollectionChangedEventHandler.Invoke(Object sender, NotifyCollectionChangedEventArgs e) at OpenRiaServices.Client.EntitySet.OnCollectionChanged(NotifyCollectionChangedAction action, Object affectedObject, Int32 index) at OpenRiaServices.Client.EntitySet.LoadEntity(Entity entity, LoadBehavior loadBehavior) at OpenRiaServices.Client.EntitySet.LoadEntities(IEnumerable``1 entities, LoadBehavior loadBehavior) at OpenRiaServices.Client.EntityContainer.LoadEntities(IEnumerable``1 entities, LoadBehavior loadBehavior) at OpenRiaServices.Client.DomainContext.<>c__DisplayClass52_0``1.<<LoadAsync>g__LoadAsyncImplementation|0>d.MoveNext() --- End of inner exception stack trace --- at OpenRiaServices.Client.DomainContext.<>c__DisplayClass52_0``1.<<LoadAsync>g__LoadAsyncImplementation|0>d.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at System.Runtime.CompilerServices.TaskAwaiter``1.GetResult()

[Daniel-Svensson]

In 5.0 the client was changed so that the synchronizationcontext is captured per call, making the consumer responsible for calling domain operations on the ui thread (if required due to data bindings).

If you have any suggestions of how to make this more clear, so that other can be helped, please create a PR to improve the changelog.md

[dekenless]

Ah, I see this now: #211

So, currently there is not a mechanism to have the call execute on a non-ui thread but have LoadAsyncImplementation (the part where the entities are added) execute on the ui thread?

[Daniel-Svensson]

You might be able to override submit and load on your domaincontext classes in order to pass execution on to the ui thread. But, there is no built-in support to do so.

[dekenless]

Is there a timeline for version 5.1 or an estimate of when you think a final release will be made?

[lindellhugo]

Hi!

Yes, we hope that we can deliver it in the beginning of the summer.
If you are eager, the latest preview (preview-5) are quite stable and can be considered production ready.

[Daniel-Svensson]

5.1 has been released with some nice updates, there might still be some lagging work to update release notes a bit more but at the moment you will need to look though all preview releases to see all changes since 5.0