-
-
Notifications
You must be signed in to change notification settings - Fork 179
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
Unintended multiple entry point calls on MonoBehaviour #709
Comments
I think I may have found the issue. It seems to be related to RegisterComponentInHierarchy using Lifetime.Scoped by default. This could be causing the multiple calls each time a new child scope is loaded. I’m not entirely certain if this is the root cause, but it appears likely. Would using Lifetime.Singleton instead resolve the issue, or is there another recommended approach to prevent these repeated injections in child scopes? |
Thanks for looking into this. Your conclusion makes sense, however unfortunately there is no option to change the lifetime to singleton when calling RegisterComponentInHierarchy. |
I believe that entry point interfaces might not be ideal for use with MonoBehaviour components, as the pure C# entry points are actually intended as a replacement for MonoBehaviour. Using entry points on MonoBehaviour can lead to issues with lifecycle management, especially when dealing with scope hierarchies, as seen here. |
One discovery from that refactor, is that calling
this is due to
|
It would be cool if |
I had same issue, and researched a lot of code, finally get to multi-injection into same object, that was so strange. The problem was really in |
I have read through the discussion of this issue. First, for RegisterComponentInHierarchy, I would change Lifetime to Singleton. (This would be a destructive change and would probably result in an error if the same type was registered multiple times, but I think there is a workaround as follows. builder. Register<IReadOnlyList<YourBehaviour>> (c =>
{
return UnityEngine.Object. FindObjectsOfType<YourBehaviour> ();
}, Lifetime. Singleton);. On the other hand, there is probably no need to use the EntryPoint interface for MonoBehaviour, and that was not the intended use. |
The main reason for using the entry points is because we have more reliable sequencing - e.g. we can use the "Post" versions to do work that depends on other work being initialized first, so basically more fine-grained and reliable sequence compared to Unity's methods. I think the ideal would be to allow specifying lifetime on calls to RegisterComponentInHierarchy, could be an optional parameter defaulting to Singleton (or Scoped if you don't want to introduce a potentially breaking change). Thanks for getting back to us on this! |
Hi,
Thanks for building and maintaining VContainer - so far we're really happy to use it, finding it a good improvement over Zenject.
However, we have run into a problem that we suspect is a bug in the framework. It seems that
MonoBehaviour
s that implement "entry point interfaces" (e.g.IInitializable
,IStartable
,IPostStartable
, etc.) get called multiple times - once per child scope loaded.[Inject]
decorated methods also appear to suffer from the issue of being called once per child scope loaded.So binding a
MonoBehaviour
that implements an entry point interface will have its method called multiple times, despite its scope never being unloaded or reloaded. You don't even need separate scenes to replicate it, as its only tied to loading more VContainer child scopes it seems. ThusMonoBehaviour
s bound in a "root" / "grand parent" scope will have their entry points called 3 times (one for itself, one for the parent and one for the child).At a glance it seems that this issue is a duplicate of this issue, but since that has been closed and we are still replicating the bug in v1.6.3 it seems that either the issue was not fully resolved, or that it has reappeared. Also that issue appears to have been caused by bindings in the child scope, whereas here the issue seems to stem from bindings in 'parent' scopes.
Here's a minimal test project where I've set up a case to replicate the behaviour:
VContainerTestProject.zip
Steps to reproduce (already set up in the above project which can be downloaded and played out of the box):
Install latest version of VContainer from UPM in a new, empty Unity project
Set up three game objects which will have each their own
LifetimeScope
implementation in a scene, and a fourth game object for the behaviours to bind.Implement abstract base behaviour and child implementations, one for each scope, then attach all three behaviours to the
BehaviourTest
game object:Set up root -> parent -> child lifetime scope relationship setting
Press play and you should see how many times each behaviour has its entry points and inject methods called in the console log, e.g.:
So, as can be seen from the above - the behaviour bound in the root / grand parent scope has its entry points and inject methods called thrice. The behaviour bound in the parent scope has its entry points and inject methods called twice, and the child behaviour methods in the child scope are invoked (correctly) once.
This bug is a serious pain for us unfortunately and means that we've had to make workarounds. POCO/Non-
MonoBehaviour
implementations do not appear to suffer from this issue.Let me know if there's any more information I can provide to help. Thanks in advance!
The text was updated successfully, but these errors were encountered: