Thanks for the proposal,

bUnit-dev/bUnit#1532 has a discussion about this which is relevant for NHibernate too.

For the simple usages we currently have (excepted the Monitor one which would have to be slightly different), using something like:

#if NET_9_0_OR_GREATER
private readonly Lock syncLock = new();
#else
private readonly object syncLock = new();
#endif

Seems enough and would avoid adding a new dependency for users to investigate if they want it in their project or not.

Yes, it is very relevant.
bUnit-dev/bUnit#1532 (comment) in particular

Using the code you pasted above will give "CS9216: A value of type System.Threading.Lock converted to a different type will use likely unintended monitor-based locking in lock statement." when you try using it in MonitorLock / InternalLock if you do it globally, plus you won't get the performance benefits of .NET 9.0 on that class if you keep using Monitor.

As for your concern regarding the additional dependency, I understand, but what we can do is copy the code into NHibernate and just put in a comment at the top giving credit. It's not ideal, but if the dependency is a deal-breaker for you we can do that instead.

Thanks for the contribution. It is unlikely we'll be targeting .NET 9 version as it is not LTS. Also, we would like to avoid an external dependency.

Thanks for the contribution. It is unlikely we'll be targeting .NET 9 version as it is not LTS. Also, we would like to avoid an external dependency.

We could copy the code in. But if you don't intend on targeting .NET 9 that's another story because this would have to wait until .NET 10.

@fredericDelaporte a new version of Backport.System.Threading.Lock has come out that acts as a source generator and basically dropping the DLL as a dependency. If this new development makes you reconsider, I will amend this PR accordingly.