LightInject changelog

Changelog History

Page 2

• v6.1.0 Changes

  September 12, 2019

  🔄 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 Changes

  August 28, 2019

  🔄 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 Changes

  May 16, 2019

  🔄 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)

• « First
• ‹ Prev
• 1
• 2