…removed null

check on scope cache (AsyncLocal can be null on Threads coming from
Threadpool.UnsafeQueueUserWorkItem, having no null check was also the
original behavior)

Threadpool.UnsafeQueueUserWorkItem.

files

this improve resolution of singleton object that might not need a root
scope, the windsor container should be enough to resolve singletons

scopes from Threadpool.UnsafeQueueUserWorkItem

deploy packages

Major fix was to support keyed registration scenario

The previous handling of root scope is wrong, the code
set root scope in an AsyncLocal variable when WindsorServiceProviderFactoryBase
was first creatd. The problem arise with kestrel or orleans in
.NET 8, they use a Thread Pool that runs code outside AsyncLocal
so it will break resolution.
It was not possible to reproduce locally, but it was reproduced
with production code. A repro for the bug still missing.
Also we can support using a Global root scope only if we use
only ONE CONTAINER in the .NET core DI, because basic structure
does not allow to find the container that is resolving scoped component
thus we cannot determin the right root context.
Still work to do to support multiple container.

Needed to modify basic Castle.Winsor library to support
the ability from IHandler interface to get the current kernel
associated with the handler. This is needed to find the correct
root scope associated with that kernel instance.

The bug happened when you register a service with one NON keyed
component then again with KEYED components. The adapter incorrectly
checked only the first returned service for KEYED and returns null.

Identified after update to Orleans 8.1.0

If multiple concrete classes are registered in castle, when
you resolve castle resolves the first one. With Microsoft DI
is the oposite, you want the last registered. The resolution
is now fixed to honor IsDefault() because previous code registered
every component with IsDefault() if it is registered from
the adapter.

We added a new concept, an extendede property that
allows the code to understand if the dependency
was registered through the adapter (ServiceCollection)
or directly through the Container.

This allows us to change the resolution rule in case
of multiple services registered with the same name.