CSLA 8 Blazor WebAssembly can't find Backport.System.Threading.Lock package

[rockfordlhotka]

Describe the bug
When running the ProjectTracker sample in the current v8.x branch, WebAssembly code fails because it can't find the Backport.System.Threading.Lock package.

I don't know why this is required for .NET 8? If it is required, perhaps it needs to be added to the nuspec so it gets installed when CSLA 8 is referenced?

Version and Platform
CSLA version: 8.2.7
OS: WebAssembly
Platform: Blazor

[MarkCiliaVincenti]

@rockfordlhotka I'm a bit confused about how to test this. However on net8 or earlier the dll/assembly of Backport.System.Threading.Lock needs to exist otherwise it cannot polyfill. What changes would need to be done to achieve this? I was under the assumption that it was working.

[rockfordlhotka]

@MarkCiliaVincenti it is a nuget packaging issue, not a coding issue.

Prior to CSLA 9, we used nuspec files in /csla/NuGet/Definition to build the nuget packages.

I think any projects that reference the thread package need to have it added. For example:

    <dependencies>
      <group targetFramework="net8.0">
        <dependency id="Csla" version="[4.6.3-Beta10]" />
        <dependency id="Csla.Blazor" version="[4.6.3-Beta10]" />
        <dependency id="Microsoft.AspNetCore.Components.WebAssembly" version="8.0.0" />
        <dependency id="System.Net.Http.Json" version="7.0.1" />
      </group>
    </dependencies>

[MarkCiliaVincenti]

OK, so over to you then? The dependency, given you are targeting pre .NET 5.0 frameworks as well, needs to go on all target frameworks including net9.0 and one day net10.0

[rockfordlhotka]

Starting with CSLA 9 we're creating the nuget packages off the csproj files, so it is automatic.

My understanding is that this library is a pollyfill for things .NET 8 and older right? So it isn't necessary for .NET 9+ code?

[MarkCiliaVincenti]

It IS necessary for .NET 9+

Please read through https://github.com/MarkCiliaVincenti/Backport.System.Threading.Lock for a minute to understand some implications. With the 'clean method', you can, and are advised to, conditionally exclude the dependency for net9.0+.

However, the clean method is only available for .NET 5.0 or later. I made this decision in the library so that this method is not used on .NET Core 3.1 or earlier, because the way the code would end up working in this case would not be 100% hardened against thread aborts and there could be rare (and mostly theoretical) circumstances where a thread could be aborted (since .NET Core 3.1 and earlier support thread aborts) at a very specific time between two lines of code which would result in the lock not being released.

Therefore, I shifted csla to the correct and safer 'factory method'. However, this requires the dependency to always exist, because otherwise it would not find the factory class and method.

If one day you decide to drop support for anything preceding .NET 5.0, which all have race conditions of their own to be honest, then you can switch from the factory method to the clean method, and drop the library as a dependency for .NET 9.0+.

[MarkCiliaVincenti]

By the way while you're at it, you might want to fix the consolidation issue. There's two csproj files depending on v2.0.5 and csla.csproj depending on v2.0.3

[rockfordlhotka]

Understood, thank you.

I expect to support net48 basically forever.

[MarkCiliaVincenti]

Understood, thank you.

I expect to support net48 basically forever.

net48 at least is hardened against thread aborts in the lock statement (unlike 3.5 and earlier).
but it's not hardened against thread aborts in the using statement. It's possible to abort a thread exactly as it finishes going through the 'using' and obtaining a resource, and when the abort happens no disposing ends up happening.

[StefanOssendorf]

Understood, thank you.
I expect to support net48 basically forever.

net48 at least is hardened against thread aborts in the lock statement (unlike 3.5 and earlier). but it's not hardened against thread aborts in the using statement. It's possible to abort a thread exactly as it finishes going through the 'using' and obtaining a resource, and when the abort happens no disposing ends up happening.

Out of curiosity. Could you provide any details on that thread abort stuff with net48 or earlier? Thanks

[MarkCiliaVincenti]

@StefanOssendorf pre net framework 4.0 using lock on an object you could be trying to abort a thread or ASP.NET would be doing it for you) and it might leave the lock taken.

Pre net 5.0, you could be relying on using and because of an ill timed thread abort it would have gone through the code inside the using but could fail to dispose the object.

[StefanOssendorf]

Yeah. But does some written articles/patch notes or something similiar exist to that problem?

[MarkCiliaVincenti]

I'm sure they do. Might write my own, but I did see something about the using pattern last week. Don't have the time to look it up again though.