Update to .NET 10.0.0

[rockfordlhotka]

#4347

[rockfordlhotka]

MAUI build has some errors, still working on those

[StefanOssendorf]

I have a question about #4737 .
The new AllowNull defaults to false which means we are changing the default behavior. Previously it was GetService which allows null to be returned. Shouldn't we default to true?

[rockfordlhotka]

MAUI build has some errors, still working on those

@Bowman74 the issue is that the viewmodel type uses a resource string from Csla.dll - but in the release build that resource is optimized away because it isn't actually used in Csla.dll.

I don't know if we should have another resource file just for Csla.Maui? Or figure out how to suppress the optimization by the compiler.

[rockfordlhotka]

I have a question about #4737 . The new AllowNull defaults to false which means we are changing the default behavior. Previously it was GetService which allows null to be returned. Shouldn't we default to true?

Hmm. I thought the [Inject] parameters were always non-null. Maybe I was wrong? In which case I'd think we'd want to preserve backward compatibility - but also it makes we wonder why I made that change at all, since it was to enable passing null values.

[StefanOssendorf]

I have a question about #4737 . The new AllowNull defaults to false which means we are changing the default behavior. Previously it was GetService which allows null to be returned. Shouldn't we default to true?

Hmm. I thought the [Inject] parameters were always non-null. Maybe I was wrong? In which case I'd think we'd want to preserve backward compatibility - but also it makes we wonder why I made that change at all, since it was to enable passing null values.

The old behavior was GetService. So we should default to true. Maybe we should adjust the new property from bool to bool?. null means old behavior: GetService. Exception: nrt is enabled so the declaration is used? 🤔

Just to be clear: I find this feature good.

[StefanOssendorf]

MAUI build has some errors, still working on those

@Bowman74 the issue is that the viewmodel type uses a resource string from Csla.dll - but in the release build that resource is optimized away because it isn't actually used in Csla.dll.

I don't know if we should have another resource file just for Csla.Maui? Or figure out how to suppress the optimization by the compiler.

Can't you just force a reference to that with _ = Resource.Foo?

[Bowman74]

@rockfordlhotka There are ways to suppress for some resources. Let me give you a call so I can understand the issue.

[Bowman74]

MAUI build has some errors, still working on those

@Bowman74 the issue is that the viewmodel type uses a resource string from Csla.dll - but in the release build that resource is optimized away because it isn't actually used in Csla.dll.

I don't know if we should have another resource file just for Csla.Maui? Or figure out how to suppress the optimization by the compiler.

@rockfordlhotka ,
If you let me know the branch, what is failing (symptoms) and how to reproduce I'll get it.

[rockfordlhotka]

MAUI build has some errors, still working on those

@Bowman74 the issue is that the viewmodel type uses a resource string from Csla.dll - but in the release build that resource is optimized away because it isn't actually used in Csla.dll.
I don't know if we should have another resource file just for Csla.Maui? Or figure out how to suppress the optimization by the compiler.

@rockfordlhotka , If you let me know the branch, what is failing (symptoms) and how to reproduce I'll get it.

Here's the branch:

https://github.com/MarimerLLC/csla/tree/dev/4347-net10

In the CLI do dotnet pack csla.build.maui.sln or do a Release build in VS2026. You'll see the build errors about the missing resource right off.

[rockfordlhotka]

MAUI build has some errors, still working on those

@Bowman74 the issue is that the viewmodel type uses a resource string from Csla.dll - but in the release build that resource is optimized away because it isn't actually used in Csla.dll.
I don't know if we should have another resource file just for Csla.Maui? Or figure out how to suppress the optimization by the compiler.

Can't you just force a reference to that with _ = Resource.Foo?

Somewhere in the Csla project source code where that won't get optimized away?

[Bowman74]

@rockfordlhotka,
On it, I've already got the beta VS installed as I've been playing with it, so not a problem.

Also, yes that solution would probably be linked away because nothing is using it anywhere.

[Bowman74]

dotnet pack csla.build.maui.sln

Able to reproduce. Let you know when I have something.

[Bowman74]

MAUI build has some errors, still working on those

@Bowman74 the issue is that the viewmodel type uses a resource string from Csla.dll - but in the release build that resource is optimized away because it isn't actually used in Csla.dll.
I don't know if we should have another resource file just for Csla.Maui? Or figure out how to suppress the optimization by the compiler.

Can't you just force a reference to that with _ = Resource.Foo?

Somewhere in the Csla project source code where that won't get optimized away?

OK, have to run to dinner. I was able to look at the platform specific Csla assemblies in the object browser. Csla.Properties.Resources.UnsupportedXamlListTypeForModel is in there, it wasn't linked away. So the issue likely is with the linker in the Csla.Xaml compile. I'll let you know when I have it sorted after dinner.

[Bowman74]

@rockfordlhotka
Good news, all figured out. There was never really a problem. Here is the long and short of what is happening. Remember when we separated out the MAUI build? This is related to the change in process that happened due to that. For Debug builds the MAUI project references the csla .csproj files. For Release builds it references an already deployed nuget package specified in the project file. Well when we were doing dotnet pack, the csla.xaml.maui.csproj project still references the csla 9.1.x package at nuget.org. Well, that version apparently doesn't have the stuff we are looking for, and shouldn't be the version of package we are compiling against for 10.x anyway.

The proper process for the new separated MAUI solution for a new major release is:

• pack the csla.build solution packages to create the nupkg file
• deploy the csla.build solution package to nuget.org
• change the version number in csla.xaml.maui.csproj to reference the newly deployed csla package in nuget.org
• pack the csla.xaml.build solution packages to create the nupkg file
• deploy the csla.xaml.build solution package to nuget.org

For a test on my machine I changed the reference for csla on release builds to be csla version 10.0.0-beta-0010-g983ce0980c. This is the latest version in nuget.org. I then did dotnet pack csla.maui.build.sln and it ran correctly. So the only "change" you will need to make is to manually edit the csla.xaml.maui.csproj to reference the proper nuget.org csla package.

Edit to add:
It looks like we have been forgetting to update the csproj file for a while. All the .net 10 beta csal.maui packages deployed reference the csla 9.1.x deployed packages, not the csla 10.x beta ones.

https://www.nuget.org/packages/Csla.Maui/10.0.0-beta-0010-g983ce0980c#dependencies-body-tab

Second edit too add:
I also looks like the references to things like Microsoft.Maui.Controls in the csla.xaml.maui.csproj project also need to be updated. They are all referencing the release candidate stuff from Microsoft. Since it has been released, we should reference the released .net 10.x versions.

[Bowman74]

@rockfordlhotka I did end up checking in an updated project file that updated the MAUI references to latest release versions (housekeeping) and also update the Csla nuget.org reference to the latest Csla 10 beta. Note, I could not use wildcards (i.e. 10.0.*) for the reference as they don't seem to work for beta versions. That is to say, you will need to update the project file to use the wildcard when the first non beta Csla 10 is deployed.

Let me know if you have any questions.