Mass instantiation problem, inadequate setup?

[vvolkgang]

Hi,

Having this issue and wondering if it's a problem with the setup or a possible bug.

Mobile app, using reflection / linq auto-registration as explained in the docs. I'm using SimpleInjector to register ViewModels and Services, ViewModels (Transient) use Services (singlethons), services don't use ViewModels.

Problem

The first time we do a GetInstance of a ViewModel that receives X amount of services, ViewModels that use the same services are instantiated as well, regardless of the ViewModels being Transient or Singlethon.

Expected Behaviour

GetInstance of a ViewModel should only instanciate that object and it's dependencies, not the other ViewModels that use the same dependencies.

Is this by design or is my setup missing something?

[dotnetjunkie]

That's probably because Auto Verification is still enabled. For more information, see the documentation.

[vvolkgang]

Was missing that, thanks! That being said, running Container.Verify() (regardless of VerificationOption) triggers the same mass instantiation.

[dotnetjunkie]

running Container.Verify() (regardless of VerificationOption) triggers the same mass instantiation.

Sure. That's what Verify does. It tests if instances can be created.

[vvolkgang]

Got it, will have to turn off AutoVerification!

Was expecting AutoVerification / Verify() process to just check dependencies using reflection, because it would throw away Transient instances. For a mobile scenario verifying slows down the startup (and in my usecase was triggering background initialization processes causing all sorts of unwanted consequences).

Thanks for helping out so quickly!

[dotnetjunkie]

For a mobile scenario verifying slows down the startup

For scenarios where startup performance is crucial, you should prevent verification at startup and move that to an integration test, as mentioned in the documentation.

[vvolkgang]

You're right, missed that!