v6.2.0

Change Log

v6.2.0 (10/16/2019)

Full Changelog

Merged Pull Requests

Added LifeSpanAttribute (10/16/2019) #514 (seesharper)

This PR adds the LifeSpanAttribute that makes it possible to indicate the lifespan of a given lifetime. We will use this information later on for validation purposes such as captive dependencies

Closed Issues

• Confusion: PerScopeLifetime or PerRequestLifeTime for request scoped services? (9/12/2019) #494 (Shazwazza)

v6.1.0

Change Log

v6.1.0 (9/12/2019)

Full Changelog

Merged Pull Requests

Added better docs around scoping (8/29/2019) #501 (seesharper)

Added a buy me a coffee link (8/29/2019) #502 (seesharper)

Feature/enable current scope (9/1/2019) #504 (seesharper)

This PR allows the container NOT to maintain the current scope. For instance in AspNet.Core, services are always requested directly from the scope and maintaining a current scopes is just unnecessary overhead.
Performance improvements for scoped/tracked services (9/12/2019) #505 (seesharper)

This PR introduces a few performance improvements when requesting services that requires a scope.

Also added support for disabling the "current scope" through ContainerOptions.EnableCurrentScope
Added support for configure action (9/12/2019) #506 (seesharper)

This PR adds support for configuring the ContainerOptions using a delegate.

var container = new ServiceContainer(o => o.EnablePropertyInjection = false);

Requested by @haavamoa 😎
Document EnableCurrentScope (9/12/2019) #507 (seesharper)

Use ContainerOptions.Default (9/12/2019) #508 (seesharper)

This PR fixes a bug introduced in #506 where we did not respect ContainerOptions.Default

Thanks to @haavamoa for spotting the error
Fixes #476 (9/12/2019) #509 (seesharper)

This PR fixes #476 by not passing the emitters and making sure that we register all available services.

Closed Issues

• Consider passing the current scope to factory methods (8/28/2019) #475 (seesharper)
• ServiceContainer.Clone() throws System.IndexOutOfRangeException (9/12/2019) #476 (denispakizh)
• LightInject 6.0 design notes (9/12/2019) #499 (seesharper)

v6.0.0

Change Log

v6.0.0 (8/28/2019)

Full Changelog

Merged Pull Requests

Updated an xmldoc typo (7/12/2019) #491 (Hammerstad)

Updated a typo in the xmldoc for ContainerOptions.LogFactory
Update version (8/2/2019) #493 (danielmarbach)

Given /~https://github.com/seesharper/LightInject/blob/master/src/LightInject/LightInject.csproj#L5 should the version also be reflected in the source file?
Added Scope Performance tests (8/11/2019) #498 (seesharper)

Flow the scope when possible (8/28/2019) #500 (seesharper)

This PR adds support for "flowing" the scope whenever possible.

This means that we pass the scope that requested a service throughout the object graph.

Example

container.RegisterScoped<IFoo>(factory => new Foo());

The factory passed into the factory delegate is an IServiceFactory and this used to always be the ServiceContainer implementing the IServiceFactory interface. What is changed is that we now pass in the Scope which also implements IServiceFactory.

When LightInject was born, there was always this notion of a current scope. An ambient context that can be used to access the current scope.
It supports scenarios like

using (container.BeginScope())
{
   var foo = container.GetInstance<IFoo>(); 
}

The way this works is that when IFoo is requested we ask for the current scope and use that scope for resolving the instance.

Then we introduced support for getting a service directly from a scope.

using (var outerScope = container.BeginScope())
{
  using(var innerScope = container.BeginScope())
	{
		var outerFoo = outerScope.GetInstance<IFoo>();
    var innerFoo = innerScope.GetInstance<IFoo>();
  } 
}

The way that this used to work was that we swapped the current scope with the scope from which the service was requested. After we resolved the service we restored the current scope to the previous current scope.

This was problematic in a number of ways.

• Swapping the current scope performs really bad as most of the time the current scope is backed by an AsyncLocal<T>.
• Deferred resolution such as Func<T> and Lazy<T> that always relied on the current scope could end up using the "wrong" scope if someone or something started a new scope using container.BeginScope which in turn sets the current scope to new newly created scope.
• Multiple parallel scopes was almost impossible to get right because of the assumption that we always have the correct current scope.

Instead of always relying on the current scope, we pass the scope throughout the code that is generated to resolve an instance. One important aspect of this is that we do this with as little breakage as possible. That means that of the service is directly requested from the scope, we pass that scope without messing with the current scope. If we request a service from the container, the current scope will be used as before.

It should be noted that requesting service directly from the scope is the preferred way with regards to performance and correctness. We will not remove support for the ambient scope, but we might emit a warning log message in the future.

Closed Issues

• Decorator patter with a lifetime that doesn't match the default (5/23/2019) #478 (bounav)
• ASP.NET Core SetCompatibilityVersion(CompatibilityVersion.Version_2_2) Breaks LightInject (5/23/2019) #482 (nystrup)
• AspNetCore 2.2 AspNetCoreHostingModel InProcess not working (5/22/2019) #488 (valeriob)
• Issue w/ Lazy<> and Scoped unit tests. (8/9/2019) #497 (danyhoron)

v5.5.0

Change Log

v5.5.0 (5/16/2019)

Full Changelog

Merged Pull Requests

Remove childscope test (5/15/2019) #486 (seesharper)

We used to throw an exception when a parent scope was disposed before all child scopes were disposed. This turns out to be a problem in AspNet Core specially when using HttpClientFactory.
This check has been in LightInject since the beginning, but there is no danger in removing this check as long as all scoped are eventually disposed.
Bumped to version 5.5.0 (5/16/2019) #487 (seesharper)

Closed Issues

• Custom Dependensies selectors (2/4/2019) #473 (AlexandrSitdikov)
• Resolve dependencies requiring an implementation created by a parameter factory (3/2/2019) #477 (BrutalSimplicity)
• ASP.Net Core PerLogicalCallContextScopeManagerProvider Thread Safety (5/2/2019) #483 (AlexFlat)
• Conditional constructor parameter injection (5/7/2019) #484 (bounav)

v5.4.0

Change Log

v5.4.0 (1/25/2019)

Full Changelog

Merged Pull Requests

Added unit testing doc (1/19/2019) #469 (seesharper)

Adds docs regarding unit testing
Added missing register concrete service overloads (1/24/2019) #470 (seesharper)

Bugfix/ignorecase opengenerics (1/24/2019) #471 (seesharper)

This fixes a bug where name open generic services was not treated as case-insensitive services.
Added support for SDK style source packages (1/25/2019) #472 (seesharper)

Fixes #457 and now adds support for a SDK style source package.

Note that this also removed the support for source packages in legacy projects using the "old" csproj format.

Closed Issues

• Support for PackageReference in LightInject.Source (1/25/2019) #457 (alanisaac)
• One singleton for different types (1/9/2019) #461 (Karnah)

v5.3.0

Change Log

v5.3.0 (12/10/2018)

Full Changelog

Merged Pull Requests

Feature/variance filter (12/10/2018) #463 (seesharper)

Adds support for setting a variance filter that determines if variance should be applied for a given IEnumerable<T> service

Closed Issues

• ASPNET errors with Entity Framework (11/12/2018) #458 (bsoulier)

v5.2.1

Change Log

v5.2.1 (11/10/2018)

Full Changelog

Merged Pull Requests

fixed Lazy Decorators header (10/4/2018) #455 (dadhi)

SourceLink and XML comments (11/10/2018) #460 (seesharper)

Adds support for sourcelink enabled pdb file and xml comments in the NuGet package.

Closed Issues

• How to I specify a specific type in contructor injection (10/19/2018) #456 (jeff-pang)

v5.2.0

Change Log

v5.2.0 (9/28/2018)

Full Changelog

Merged Pull Requests

Lazy with named services (9/12/2018) #443 (seesharper)

Fixes #427 by using the service name when resolving the underlying value for Lazy<T>
Add convenience register extension methods (9/13/2018) #446 (seesharper)

Adds support for RegisterTransient, RegisterScoped and RegisterSingleton .

This means that we can do

container.RegisterScoped<IFoo, Foo>();

instead of

container.Register<IFoo, Foo>(new PerScopeLifetime());

Default to PerLogicalCallContextScopeManagerProvider (9/27/2018) #450 (0xced)

On target frameworks where it’s available, default to using PerLogicalCallContextScopeManagerProvider instead of PerThreadScopeManagerProvider.

See also #153.
Added non-generic object factory (9/28/2018) #453 (seesharper)

version 5.2.0 (9/28/2018) #454 (seesharper)

Closed Issues

• Remove PCL build and simplify target frameworks (9/14/2018) #318 (seesharper)
• Lazy is not working with named service (9/12/2018) #427 (VishmayS)
• Recursive dependency testing (9/17/2018) #428 (kemsky)
• How to provide one of several constructor dependencies from a factory method? (9/14/2018) #435 (vegar)
• Add extension methods for lifetime registration (9/13/2018) #444 (seesharper)
• After add fluentvalidation lightinject stops registering some types, for example BinderParameter (9/13/2018) #445 (Merdok94)
• Add non-generic object factory (9/28/2018) #452 (seesharper)

v5.1.10

Change Log

v5.1.10 (9/10/2018)

Full Changelog

Merged Pull Requests

Bugfix/opengeneric (9/10/2018) #442 (seesharper)

Fixes a bug where resolving open generic types passed an empty list of services to DefaultServiceSelector

v5.1.9

Change Log

v5.1.9 (9/7/2018)

Full Changelog

Merged Pull Requests

Support named dependency convention when using custom ServiceSelector (8/24/2018) #438 (henrihs)

Try to resolve dependencies by using parameter names when several mathcing services are registered. When using a custom DefaultServiceSelector, this behaviour is broken.
Feature/netstandard2.0 (8/24/2018) #439 (seesharper)

Adds netstandard2.0 as one of target frameworks
Pr438 (9/7/2018) #440 (seesharper)

This fixes a bug that caused the fallback to dependency name (constructor or property) to fail when using a DefaultServiceSelector that always resolves a default service.
Set version to 5.1.9 (9/7/2018) #441 (seesharper)

Sets the correct version 5.1.9

Closed Issues

• Add netstandard 2.0 support (8/27/2018) #429 (mitchdowd)