Stashbox v5.10.1

Added

• ParentDependency flag for ResolutionBehavior. It indicates that parent containers (including indirect all ancestors) can only provide dependencies for services that are already selected for resolution.

Fixed

• During factory resolution, the type map check failed for registrations like: .Register<IService>(c => c.WithFactory(/* ... */).AsServiceAlso<IAnother>()). Now, the container gets the implementation type from the generic context where it's possible.

Stashbox v5.10.0

Changed

• Each Resolve() method now accepts a ResolutionBehavior flag parameter. It determines which level of the container hierarchy can take part in the service resolution. Possible values:
  • Parent: Indicates that parent containers (including indirect all ancestors) can participate in the resolution request's service selection.
  • Current: Indicates that the current container (which initiated the resolution request) can participate in the service selection.
  • Default: The default behavior, it's used when the parameter is not specified. Its value is Parent | Current, so the parents and the current (which initiated the resolution request) container can participate in the resolution request's service selection.
• CreateChildContainer() now accepts an attachToParent boolean parameter, which indicates whether the parent container's disposal should also dispose the child. It defaults to true.
• ITenantDistributor and TenantDistributor types became obsolete. Their functionality is available on IStashboxContainer.
  • ITenantDistributor.ConfigureTenant() -> IStashboxContainer.CreateChildContainer()
  • ITenantDistributor.GetTenant() -> IStashboxContainer.GetChildContainer()
• Calling Validate() on a container will execute validation on each of its child container if it has any.

Fixed

• IEnumerable<T> and ResolveAll() requests were not taking services in parent containers into account. Now, it respects the given ResolutionBehavior and as its default value is Parent | Current, IEnumerable<T> requests will return services from parent containers by default.
• Decorator selection during a resolution request was not take parent containers into consideration. It now respects the given ResolutionBehavior parameter.

Stashbox v5.9.1

Fixed

• The per-request expression cache stored the underlying expressions with type conversion to the requested service type. This caused type mismatch exceptions when a service was registered to multiple base types. Now, the cache stores the raw instantiation expression and the conversion happens one layer above when needed.

Stashbox v5.9.0

Fixed

• Resolving IServiceProvider always returned the actual resolution scope, which prevented the usage of custom registered implementations. Now, the container returns the actual resolution scope only when no other IServiceProvider implementation is registered.

Stashbox v5.8.2

Fixed

• #133: In some cases, open generic constraint validation rejected resolution requests for generic arguments with struct constraint.

Stashbox v5.8.1

• #132: Open generic constraint validation rejected resolution requests for interface type generic arguments with class constraint.

Stashbox v5.8.0

Fixed

• Batch registration (like .RegisterAssembly() and .RegisterTypes()) produced individual registrations for each interface/base type and implementation type pairs.

  For an example class like class Sample : ISample1, ISample2 { } the registration mapping looked like this:

  ISample1 => NewRegistrationOf(Sample)
  ISample2 => NewRegistrationOf(Sample)
  

  Now each interface/base type is mapped to the same registration:

   registration = NewRegistrationOf(Sample)
   ISample1 => registration
   ISample2 => registration
  

Changed

• There are cases where the above fix for batch registration indirectly breaks the following service type filter format:

  container.RegisterAssemblyContaining<ISample>(configurator: options =>
      {
          if (options.ServiceType == typeof(IService))
              context.WithScopedLifetime();
      });

  This worked before (and still works if the related service implements only a single type) because for each implemented type there was an individual registration configuration object passed to the configurator delegate.

  Now it will not work properly if the bound type implements more than one type, as only one object containing each implemented type is passed to the delegate.

  Therefore, to still support this case, a new service type checker method was introduced:

  container.RegisterAssemblyContaining<ISample>(configurator: options =>
      {
          if (options.HasServiceType<IService>()) // or .HasServiceType(typeof(IService))
              context.WithScopedLifetime();
      });

Stashbox v5.7.1

Added

• net7.0 target framework.

Changed

• Replaced many typeof() calls with static type cache.

Stashbox v5.7.0

Changed

• ITenantDistributor now extends IStashboxContainer for easier integration.

Stashbox v5.6.0

Added

• WhenResolutionPathHas() & WhenInResolutionPathOf() registration options for handling more conditional resolution cases. They extend the original parent type and attribute conditions with inheritance.

Fixed

• Name comparison during named scope resolution.