Version 6.2.0 release

[rockfordlhotka]

I am pleased to announce the release of CSLA version 6.2.0. Mostly bug fixes, but with one enhancement: the data portal ExecuteAsync method now accepts parameters.

Using ExecuteAsync with parameters is more like a fetch than an update. In other words, the data portal does this:

1. Client-side ExecuteAsync accepts parameters and passes them to the server
2. Server-side data portal creates an instance of your command type
3. Server-side data portal invokes your Execute operation method, passing it the parameters
4. Server-side data portal returns the instance of the command object to the client
5. Client-side data portal returns the instance of the command object to the calling code

The original behavior of the ExecuteAsync method is unchanged (if you create a command object on the client and execute it).

Full details of this release are here: https://github.com/MarimerLLC/csla/releases/tag/v6.2.0

[mtavares628]

@rockfordlhotka is there a reason why the synchronous data portal Execute method doesn't also have this overload to accept parameters? There are certain cases where I execute a command object synchronously instead of async and if the synchronous version doesn't allow parameters, then it means that the command would still need to have a create method and use properties to pass in parameters. Just wondering if this was a design decision or an oversight. Thanks.

[rockfordlhotka]

Really an oversight on my part.

[Chicagoan2016]

@rockfordlhotka For #3044 it looks like we have to use compiler directives? We have a business library currently used in Winforms but could be called from other UI platforms in the future.

[rockfordlhotka]

I don't understand your question. The #3044 change affects only Csla.Xaml, and impacts the default for setting up the principal object as the app loads.

It doesn't affect Windows Forms at all, because Windows Forms only works on the Windows operating system, and so should always have access to the WindowsPrincipal type as it has in the past.

[Chicagoan2016]

Our business library is currently used by WinForms but in the future, we would move to Blazor (or WPF?). I wasn't sure if we have to change our Security code. Our CustomPrincipal is inherited from CslaPrincipal and our CustomIdentiy from CslaIdentityBase

[rockfordlhotka]

The old security model has no future. Microsoft is moving toward ClaimsIdentity as the only answer. it is the only thing supported in aspnetcore or Blazor.

You'll need to figure out how to move to ClaimsPrincipal/ClaimsIdentity at some point.