Fix issues with Backport.System.Threading.Lock package

[rockfordlhotka]

MarkCiliaVincenti/Backport.System.Threading.Lock#6

It looks like we either

1. Go through all the projects and fix all the references/usage of the library
   • Remove the offending lines from Build.Build.props
   • For projects that actually use the library, keep it and add necessary lines to csproj
   • For projects that don't use the library, but just reference it today due to the viral mistake, remove the reference entirely
2. Go through all the projects and remove all usage of the library

Right now I'm leaning toward option 2, as I'm not convinced the value of the library is worth the ongoing effort.

[StefanOssendorf]

If we go route 2. How will we handle the locks?
The new Lock object does seem to have performance improvements we should not miss out - I think.

[rockfordlhotka]

If we go route 2. How will we handle the locks? The new Lock object does seem to have performance improvements we should not miss out - I think.

That is a good point, though I'd like to see some hard data about how much different the performance improvements actually make.

I must confess that I put in option 2 due to frustration, as the Backport package dependency seems to cause random build issues over time and that is frustrating when it happens while someone is trying to work on an actual CSLA issue.

[StefanOssendorf]

I understand that :)
Here's a post from the .Net blog: https://devblogs.microsoft.com/dotnet/performance-improvements-in-net-9/#threading
It's "only" a difference of ~0.5ns but I think with this kind of stuff it stacks up when used in hot path scenarios.
I don't have an overview when or where we use lock extensivly. So if it's not used in hot path scenarios we could stick to the old style for now.

[Bowman74]

As an interesting aside, from what I can tell reading the background on System.Threading.Lock, the motivation was to give developers more control over the locking process and not necessarily performance. Looks like MS got an extra bonus with the new design. As with all new language features, their use can be problematic in libraries like CSLA which still target and compile against earlier versions.

I guess it is possible to avoid a dependency is for CSLA to create its own Locking abstraction class that contains all the required #if NET9_0_OR_GREATER type code to handle differences in the locking syntax when compiled in different versions of dot net. I don't know if it is a good idea or a bad idea, but it is an idea that I believe has been used before. The CSLA usage of locking looks pretty simple so the primary benefit of the new locking type would seem to be to grab that performance boost for people on dot net 9+.