CSLA 10.0.0 alpha-0008 pre-release online

[rockfordlhotka]

I have pushed a pre-release of CSLA 10 to NuGet.

We do have a few open backlog issues still, and this is a work in progress, but for those who are interested in helping with the testing effort, here's the first real opportunity.

There is a Upgrading to CSLA 10 doc online for your reference.

Please report any issues or bugs you find.

[ossendorf-at-hoelscher]

#4730 broke the source gen nuget packages.
After updating to CSLA10 I had to make the package reference look like this to get it working:
(Note: I'm using central package management so there are no version numbers there)

<PackageReference Include="Csla.Generator.AutoImplementProperties.CSharp" />
<PackageReference Include="Csla.Generator.AutoSerialization.CSharp" />

The normal behavior referencing it like this:

<PackageReference Include="Csla.Generator.AutoSerialization.CSharp">
  <PrivateAssets>all</PrivateAssets>
  <IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
</PackageReference>

results in

I could get rid of the compilation error with

<PackageReference Include="Csla.Generator.AutoImplementProperties.CSharp" PrivateAssets="all" ExcludeAssets="runtime" />
<PackageReference Include="Csla.Generator.AutoSerialization.CSharp" PrivateAssets="all" ExcludeAssets="runtime" />

but that led to a runtime error where the attribute could not be loaded.

I think either the project structure or nuget packaging does something wrong.
My own source gen also uses an attribute and is usable with just
<PackageReference Include="Ossendorf.Csla.DataPortalExtensionGenerator" PrivateAssets="all" ExcludeAssets="runtime" />. No compilation or runtime error using the generated methods.

[StefanOssendorf]

From my researching on this, it sounds like the fact that our nuget package has the generator and an attributes assembly means that dotnet pack can't actually do the right thing.

So what I've done, in the blazorexample branch (draft pr) is to set it up so the nuget package reference is "normal" - nothing special. That brings in both assemblies into the right locations.

I suspect that if someone wants to prevent the generator from being deployed downstream they may need to manually alter the PackageReference to make that work correctly, but it isn't something dotnet pack and/or NuGet can properly do automatically.

I don't think that's the correct solution. Comparing our nugets to my source-gen nuget there is only one obvious difference:

I'm packing the attributes dll besides the generator file. I don't know why but it's probably mentioned in andrew locks blog posts.

[rockfordlhotka]

Can you compare to my working branch where I've altered some of the config?

https://github.com/MarimerLLC/csla/tree/dev/blazorexample10

Or even change my branch and we can try whatever you are thinking.

[StefanOssendorf]

I'll try to take a look tomorrow evening.

[StefanOssendorf]

Ok. I looked into it and I think our "problem" is that we inspect all business object during creation if they have the ObjectFactoryAttribute. This check forces all codes to have a dependency on the attributes necessary for our generators.
So we have some options:

1. Make the generator a normal dependency so it's flowing through the chain
2. Make sure to communicate the source-gen attribute assembly should be explicitly referenced by the final assembly (exe, ...)
3. Let's just skip/drop the whole attribute assemblies and add the marker attributes to the Csla core libary
4. The core library can take a dependency on the marker attribute assemblies

I think we should go with 3. A couple more attributes within Csla are no big deal and Csla has to be referenced. Otherwise the whole problem wouldn't exist :D. The generators are referencing the the attribute assemblies but I don't think that's actually necessary. 🤔

[rockfordlhotka]

Maybe. The same issue exists for the serialization generator, and I don't want those attributes in the core library.

Really, the attributes belong with the generator, because otherwise they are just confusing imo.

The reason it is how it is, was to come up with a pattern for building generators over time - and I didn't (and don't) think adding what amounts to disconnected attributes into the main assembly is a good long-term strategy.