Bump LightInject from 7.0.1 to 7.1.0

[dependabot]

Updated LightInject from 7.0.1 to 7.1.0.

Release notes

Sourced from LightInject's releases.

7.1.0

Change Log

v7.1.0 (05/21/2026)

Full Changelog

Merged Pull Requests

Align keyed service tests with MS.DI spec and fix AnyKey enumeration (05/21/2026) #​613 (seesharper)

Summary

• Aligns KeyedMicrosoftTests.cs with the upstream KeyedDependencyInjectionSpecificationTests.cs from dotnet/runtime
• Fixes a bug where AnyKey ("*") registrations were incorrectly included in IEnumerable<T> keyed service resolution
• Bumps version to 7.1.0

Changes

Tests (KeyedMicrosoftTests.cs)

• Updated ResolveKeyedServicesAnyKeyWithAnyKeyRegistration: expects 4 services (not 5); AnyKey registrations are excluded from enumeration
• Updated ResolveKeyedServicesSingletonInstanceWithAnyKey: AnyKey registrations are not included when listing services by a specific key
• Updated ResolveKeyedSingletonFromScopeServiceProvider and ResolveKeyedScopedFromScopeServiceProvider: added assertions that direct AnyKey lookup throws
• Added 13 new tests: CombinationalRegistration, ResolveKeyedServicesAnyKeyConsistency, ResolveKeyedServicesAnyKeyConsistencyWithAnyKeyRegistration, ResolveKeyedServicesAnyKeyOrdering, ResolveWithAnyKeyQuery_Constructor, ResolveWithAnyKeyQuery_Constructor_Duplicates, ResolveWithAnyKeyQuery_InstanceProvided, ResolveWithAnyKeyQuery_InstanceProvided_Duplicates, ResolveRequiredKeyedServiceThrowsIfNotFound, SimpleServiceKeyedResolution

Fix (LightInject.cs)

In CreateEmitMethodForEnumerableServiceServiceRequest, two cases fixed (both variance and no-variance branches):

• GetKeyedServices(AnyKey): added && k.ServiceName != "*" so the "*" registration itself is not returned
• GetKeyedServices("some-key"): removed || k.ServiceName == "*" so AnyKey wildcard registrations don't appear in specific-key enumerations

Single-service resolution with AnyKey wildcard fallback is unaffected.

Test plan

• All 1561 tests pass

🤖 Generated with Claude Code

7.0.2

Change Log

v7.0.2 (05/19/2026)

Full Changelog

Merged Pull Requests

Fixed issue #​606: properly support named Lazy services (04/27/2025) #​607 (kemsky)

Fixes issue #​606.

I'm not entirely sure that all cases are covered, but tests passed and my issue is resolved.
Fix thread safety of disposableObjects in ServiceContainer.Dispose (05/19/2026) #​611 (seesharper)

Summary

• TrackInstance and Dispose() both accessed disposableObjects (List<IDisposable>) without any synchronization, creating a data race under concurrent load — most visibly when services are still being first-resolved on background threads while the container is being disposed. Depending on .NET version and timing, this manifests as InvalidOperationException: Collection was modified or ArgumentException: Destination array was not long enough.
• Dispose() also had no guard against the same instance being disposed more than once (e.g. if two container lifetimes happened to return the same object).

Changes

• TrackInstance — wraps disposableObjects.Add() in lock(container.lockObject), matching the locking pattern already used by Scope.TrackInstance.
• ServiceContainer.Dispose() — atomically snapshots-and-clears disposableObjects under lockObject, then disposes the snapshot outside the lock so no lock is held during user Dispose() calls (avoids deadlocks). A reference-equality HashSet skips duplicate entries, consistent with how Scope.Dispose() already works.
• DisposableObjectComparer — new private nested class using RuntimeHelpers.GetHashCode for stable object-identity hashing.
• Dispose_ConcurrentWithServiceCreation_DoesNotThrow — stress test with 3 concurrent threads (2 resolving services, 1 disposing) over 1000 iterations as a regression guard.

Test plan

• All 1529 existing tests continue to pass
• New concurrent stress test passes under the fix

🤖 Generated with Claude Code
Bump version (05/19/2026) #​612 (seesharper)

Closed Issues

• Wrong using at LightInject.Source 7.0.0 nuget package (11/21/2024) #​602 (nobyArdor)

Commits viewable in compare view.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[dependabot]

Looks like LightInject is no longer updatable, so this is no longer needed.