CSLA 9 release candidate 1 online

[rockfordlhotka]

Hello everyone!

I am happy to announce that CSLA 9 release candidate 1 is now available in NuGet.

We are at the point with version 9 where the only changes expected are to fix bugs found by you, or as we update the samples in the /Samples directory. Other than bug fixes, CSLA 9 is complete and ready to go.

Please take the time to check it out and create issues here in GitHub if you find any bugs.

Here are the release notes: https://github.com/MarimerLLC/csla/blob/main/releasenotes.md

Here is a comprehensive list of changes: v8.2.7...HEAD

Check out the Upgrading to CSLA 9 document.

Don't forget to check out the new Csla.Generator packages. One provides much higher performance serialization, and the other enables radical code reduction in many business domain class scenarios.

• AutoImplementProperties
• AutoSerialization

[ossendorf-at-hoelscher]

Hi. I've just updated our CSLA from 8 to the 9-RC1.
I encountered the following issues/compilation errors:

• The new Csla.NonSerializedAttribute is now ambigious with the System.NonSerializedAttribute. Which poses the question: Which do I need to mark the field as not participating in the serialization process? (It was "introduced" in Features/add nonserialized backing fields #4197 )
• The type Csla.Serialization.SerializationFormatterFactory got removed which is not documented in the CSLA 9 upgrade guide. It was removed with Add custom serializers to MobileFormatter #4024 . I think the guide should say use ApplicationContext.GetRequiredService<ISerializationFormatter>() instead.
• InputProperties of rules are now read-only. Do we need to include that in the migration guide? So instead of assigning them just use Add/AddRange 🤔
• We should mention that the API of IParent.RemoveChild changed from void to Task. I catched that because we have promoted "not awaited calls" to errors which is not the default.

I'll update this post when I encounter other problems.

[rockfordlhotka]

Thank you, I don't think we considered that issue.

I am also not sure we need to have that attribute as a pollyfill since I very much doubt Microsoft will remove their attribute due to the widespread issues that would cause people.

[rockfordlhotka]

Oh, no, it isn't a pollyfill. The issue is the applicable scope of the original attribute and our need to apply it to properties instead of fields.

We may just need to use a different name for our attribute to avoid the conflict.

[ossendorf-at-hoelscher]

Two more compile errors added

[ossendorf-at-hoelscher]

I also get this during compilation but I don't know if it was there before:

[ossendorf-at-hoelscher]

I also get a value can not be null ArgumentNullException for principal when starting our application. I hope I can investigate this soon, but holidays are just around the corner 😅

[ossendorf-at-hoelscher]

Just created #4410 with the ArgumentNullException mentioned. Sadly that's a blocker for me to test anything further.

[ossendorf-at-hoelscher]

The analyzer exceptions are still a thing during compilation with rc3.

[ossendorf-at-hoelscher]

With the configuration changes made in v9 there is now no IContextManager registered when using this setup:

.AddCsla(
    o => o.DataPortal(
        dpo => dpo.AddClientSideDataPortal(
            cso => cso.UseLocalProxy(lp => lp.UseLocalScope = false)
        )
    )
)

This is our current setup for our testing.
But that now fails because I can't retrieve an IContextManager to set my expected users.

Is there any recommendation on how to deal with that? Should I just use AddConsoleApp to get a context manager registered?

[rockfordlhotka]

I think that might be best.

Or we could register a default.