New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Get CSLA working with Blazor #829

Closed
rockfordlhotka opened this Issue Apr 6, 2018 · 19 comments

Comments

Projects
None yet
4 participants
@rockfordlhotka
Member

rockfordlhotka commented Apr 6, 2018

Get CSLA to work with Blazor.

Right now if you reference CSLA 4.7.100 (netstandard 2.0) in Blazor the result is a linker error when Blazor attempts to compile to wasm. I think this is because some of the Microsoft assemblies used by CSLA aren't supported in the version of mono on which Blazor is based.

The short-term strategy might be to pare down the dependencies on those system assemblies (even if that means removing some CSLA functionality) to see if it is possible to get a Csla.dll that can be linked into a Blazor app.

Usage note
Based on the very experimental work so far on this issue, you can play around with it too by following these instructions:

  1. Get yourself all set up with Blazor so you can run their starting template project
  2. Pull the experimental CSLA code from here: https://github.com/rockfordlhotka/csla/tree/blazor
  3. Add the Csla.Shared project to your solution
  4. Add the Csla.Wasm project to your solution
  5. Reference the Csla.Wasm project from your Blazor project

At this point you should be able to create CSLA business classes in your Blazor project and interact with them from your views.

@rockfordlhotka rockfordlhotka self-assigned this Apr 6, 2018

rockfordlhotka added a commit to rockfordlhotka/csla that referenced this issue Apr 6, 2018

MarimerLLC#829 Create a Csla.Wasm project with pared down dependencie…
…s to get an assembly that works with Blazor.

rockfordlhotka added a commit to rockfordlhotka/csla that referenced this issue Apr 6, 2018

@rockfordlhotka

This comment has been minimized.

Member

rockfordlhotka commented Apr 6, 2018

The strategy appears to be largely successful. I was able to get the dependencies down to just these:

  <ItemGroup>
    <PackageReference Include="System.Data.Common" Version="4.3.0" />
    <PackageReference Include="System.Data.SqlClient" Version="4.3.1" />
    <PackageReference Include="System.ComponentModel.Annotations" Version="4.3.0" />
    <PackageReference Include="System.Reflection" Version="4.3.0" />
  </ItemGroup>

Without removing any functionality from CSLA - at least to get it compiled.

It may be however, that some functionality is now broken. For example, the data portal doesn't currently work in Blazor, due to an exception with System.Linq.Expressions. I'm not yet sure if that's a limitation of mono-wasm, or a missing dependency from CSLA.

Ignoring the data portal however, it is possible to create and interact with a CSLA business object in Blazor.

@rockfordlhotka

This comment has been minimized.

Member

rockfordlhotka commented Apr 6, 2018

Further experimentation seems to establish that the linker issue is with two of the serialization assemblies:

    <PackageReference Include="System.Runtime.Serialization.Xml" Version="4.3.0" />
    <PackageReference Include="System.Runtime.Serialization.Formatters" Version="4.3.0" />

I've been able to restore all the other assembly references and still have a Blazor app link and run against Csla.dll.

The data portal continues to fail with the System.Linq.Expressions issue, so I think that is a mono-wasm issue, not a system reference issue (because neither of the now-removed assembly references have anything to do with Linq).

@rockfordlhotka

This comment has been minimized.

Member

rockfordlhotka commented Apr 6, 2018

Removing the usage of System.Linq.Expressions wasn't as hard as I'd feared, because I never got around to removing the old IOS compiler directives that used to be necessary for this same reason. Added new WASM directives, rebuilt, and now the data portal works!

rockfordlhotka added a commit to rockfordlhotka/csla that referenced this issue Apr 6, 2018

rockfordlhotka added a commit to rockfordlhotka/csla that referenced this issue Apr 6, 2018

@fujiiface

This comment has been minimized.

Contributor

fujiiface commented Apr 6, 2018

This is some exciting news!

@royog

This comment has been minimized.

Contributor

royog commented Apr 6, 2018

@tfreitasleal

This comment has been minimized.

Member

tfreitasleal commented Apr 7, 2018

Hi all,

I have some notes/questions/doubts about WASM/Blazor. I started a thread about this at What is WASM/Blazor good for?

@rockfordlhotka

This comment has been minimized.

Member

rockfordlhotka commented Apr 8, 2018

CSLA appears to work in Blazor at this point, except that the data portal is encountering an issue with the DataContractSerializer - which doesn't appear to be working.

aspnet/Blazor#511

Ideally this would be resolved by mono-wasm or Blazor, but in the meantime I'm considering exploring other options (if Json.Net works in Blazor that'd be a nice workaround).

Edit: Newtonsoft.Json doesn't work in Blazor either, because they also use System.Linq.Expressions to optimize reflection, so they crash due to that limitation. Json.Net works for simple types (List<string>) but not a list of custom types.

rockfordlhotka added a commit to rockfordlhotka/csla that referenced this issue Apr 8, 2018

MarimerLLC#829 Add method to provide pre-configured HttpClient object…
… to proxy. Also, change proxy to pass values to/from the server as a string instead of byte array (due to limitation of Blazor).

rockfordlhotka added a commit to rockfordlhotka/csla that referenced this issue Apr 8, 2018

@rockfordlhotka

This comment has been minimized.

Member

rockfordlhotka commented Apr 8, 2018

SUCCESS!!

Well, mostly anyway. There's now a Samples\BlazorExample that (on the counter page) successfully gets a simple business object via the data portal from the ASP.NET Core web server.

The only issue at the moment is that the button click handler is an async method, and that appears to mess up how Blazor does data binding. So after you get the object, click the other button to increment the counter (and thus refresh data binding) to see the value. - resolved

This is extremely cool imo!

(the other current limitation is that I'm 99% sure any sort of list objects won't go through the data portal - I need to replace the one spot I'm using Json.Net with something else - probably have to write my own low-level serializer 😢 ) - the only place I'm using Json.Net is on primitive types, so there should be no issue here.

rockfordlhotka added a commit to rockfordlhotka/csla that referenced this issue Apr 8, 2018

@rockfordlhotka

This comment has been minimized.

Member

rockfordlhotka commented Apr 8, 2018

There's a StateHasChanged method that refreshes data binding if you call it at the end of an async method, so that issue is resolved.

@rockfordlhotka

This comment has been minimized.

Member

rockfordlhotka commented Apr 10, 2018

It looks like the DCS/Json.Net dependency can be avoided with simpler code: MarimerLLC/cslaforum#515 (comment)

So valuable to have other eyes on the work!!

rockfordlhotka added a commit to rockfordlhotka/csla that referenced this issue Apr 19, 2018

rockfordlhotka added a commit to rockfordlhotka/csla that referenced this issue Apr 19, 2018

@rockfordlhotka rockfordlhotka added this to the 4.7.200 milestone Apr 25, 2018

@rockfordlhotka

This comment has been minimized.

Member

rockfordlhotka commented Apr 25, 2018

The solution to the System.Linq.Expressions issue is to detect at runtime (via OS Platform/Environment) that we're running on MonoWasm and branch to the reflection code, while branching to the Linq implementation on all other platforms.

More info/background is here in the mono repo: mono/mono#7852

@rockfordlhotka

This comment has been minimized.

Member

rockfordlhotka commented Apr 25, 2018

The solution to the HttpClient limitations around passing only text is to create a new data portal channel such as HttpTextProxy or something along that line - thus allowing MonoWasm devs to set up a proxy/host that works for Blazor, while allowing other platforms to choose the existing HttpProxy that uses binary.

rockfordlhotka added a commit to rockfordlhotka/csla that referenced this issue Apr 30, 2018

@rockfordlhotka

This comment has been minimized.

Member

rockfordlhotka commented May 14, 2018

Starting at this point my plan is to disregard the initial PR and create a new PR with a cleaner implementation.

rockfordlhotka added a commit to rockfordlhotka/csla that referenced this issue May 14, 2018

rockfordlhotka added a commit to rockfordlhotka/csla that referenced this issue May 14, 2018

rockfordlhotka added a commit to rockfordlhotka/csla that referenced this issue May 14, 2018

rockfordlhotka added a commit to rockfordlhotka/csla that referenced this issue May 14, 2018

@rockfordlhotka

This comment has been minimized.

Member

rockfordlhotka commented May 14, 2018

THE CHANGE TO MOBILELIST IS A BREAKING CHANGE

MobileList used to be able to serialize any type that could be serialized by the DataContractSerializer. With the change made for wasm, there's no longer a DCS dependency, which means that MobileList can now only serialize primitive types.

rockfordlhotka added a commit to rockfordlhotka/csla that referenced this issue May 14, 2018

@tfreitasleal

This comment has been minimized.

Member

tfreitasleal commented May 14, 2018

MobileList can not only serialize primitive types.

I supposed this means that from now on, MobileList can serialize all kinds of types (including primitive types). Is this correct?

If this is correct, I don't understand how this change will break existing code.

@rockfordlhotka

This comment has been minimized.

Member

rockfordlhotka commented May 14, 2018

Prior to this change MobileList could contain any items that could be serialized by the DCS.

Because we no longer use the DCS, MobileList can now only contain primitive types (string, date, number, etc.).

It can no longer contain complex items like it could before.

(I see the confusion - I had a typo in my previous post)

@tfreitasleal

This comment has been minimized.

Member

tfreitasleal commented May 14, 2018

Oh, I see. This a breaking change indeed, and a big one. I foresee people not upgrading versions because of this limitation.

This means not even SmartDate is allowed...

Is there a way to keep the MobileList as it is now and introduce a PrimitiveMobileList with the primitives-only limitation?

@rockfordlhotka

This comment has been minimized.

Member

rockfordlhotka commented May 14, 2018

Anything that implemented IMobileObject continues to work - so SmartDate should be fine.

What stops working are arbitrary non-primitive, non-CSLA types.

The problem with adding a new type is that nobody's existing code would work in wasm. MobileList is used at some low levels (like in the principal/identity types), so no code works without fixing this issue.

@tfreitasleal

This comment has been minimized.

Member

tfreitasleal commented May 14, 2018

I retract my previous statement. If MobileList can serialize CSLA objects, the breaking change isn't that big, unless someone was using it on non-CSLA projects.

In these circumstances I don't think we need a new type.

rockfordlhotka added a commit to rockfordlhotka/csla that referenced this issue May 14, 2018

rockfordlhotka added a commit to rockfordlhotka/csla that referenced this issue May 14, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment