-
-
Notifications
You must be signed in to change notification settings - Fork 839
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Resolving an externally provided component from a lifetime scope still checks for public constructors #1433
Comments
Yeah, a ton has changed since 4.9.2 was released back in early 2019. I also know ACTNARS has been no end of trouble, like registration order matters with it and it provides a lot of weird exceptions by effectively registering everything in the system. Basically. I'm not sure we'll be able to "hop right on this." We'd love to see a PR for it, though. |
I have had a look at this, but I'm struggling to understand the root cause. Just in case it is helpful to anyone who looks at this in the future, this is what I have discovered so far. I reduced my test case further - the failure can be observed resolving what I called 'ExternalDependency' above directly. [Fact]
public void IgnoresRegisteredInstancesWithInternalCtorWhenResolvingFromScope()
{
// issue 1433
var cb = new ContainerBuilder();
var internalCtor = new TypeWithInternalCtor();
cb.RegisterSource(new AnyConcreteTypeNotAlreadyRegisteredSource());
var container = cb.Build();
using var scope = container.BeginLifetimeScope("scope1", b => b.RegisterInstance(internalCtor));
var resolved = scope.Resolve<TypeWithInternalCtor>();
Assert.Same(internalCtor, resolved);
}
|
My best bet may be to explore getting rid of our need for using ACTNARS. It was probably very originally used out of laziness... |
Describe the Bug
I have an object instance that I'm providing when creating a lifetime scope. The type's constructor is internal. When trying to resolve a component that depends on this type, I get an exception because the type has no public constructors. However, an instance of the type has been provided so there should be no need to examine its constructors.
The AnyConcreteTypeNotAlreadyRegisteredSource source needs to be registered to trigger this.
Interestingly, if you don't use a scope and do all the registrations in the container root, then the resolve succeeds.
I've encountered this issue upgrading a large application from v4.9.2 to v8.1.0. The change in behaviour started in v6.0.
Steps to Reproduce
Expected Behavior
The call to Resolve to succeed and the instance of Service1 to be created with the instance of ExternalDependency passed into its constructor.
Exception with Stack Trace
The text was updated successfully, but these errors were encountered: