c# - How does DI actually do the injection to a property? -

i searched brains out , wasn't able find suitable answer, here go! have following property in each of forms or objects:

    private rootworkitem m_rootworkitem;     [rootworkitem(inject = true)]     public rootworkitem rootworkitem {          {             if (m_rootworkitem == null) {                 m_rootworkitem = new rootworkitem();             }             return m_rootworkitem;         }     } 

note rootworkitem class have designed contains collection of services (collection). basically, services loaded external dll files using reflection , activator.createinstance, , put rootworkitem.services.

but how on earth can "inject" first rootworkitem created every other rootworkitem marked attribute in program?

how these di patterns "do" injection "into" property? know concepts of di trying write own, extremely basic di 1 single object. i've been messing reflection tons try , find suitable way , i'm not closed coming right way it.

edited more clearer question: how di framework/service know when object created contains property inject?

ie:

    class myform : form {         [rootworkitem(inject = true)]         public rootworkitem rootworkitem { get; set; }     end class      class program {         main {             myform form = new myform();             form.show();         }     end class 

how know inject property value when form created, if nothing notifies service created or needs injected?

you're asking right question: "how know inject property value when form created, if nothing notifies service created or needs injected?"

you're correct when "if nothing notifies service created or needs injected", di framework cannot job.

however, di framework does know, because use di framework create object having dependencies injected. in case, use di framework create form, aware of object , can inject dependencies.

instead of

myform form = new myform();  form.show(); 

do

myform form = diframework.createform(typeof(myform)); form.show(); 

now, di framework knows object!

essentially, new enemy of di, since means caller controlling construction of object. instead, caller meant leave responsibility else, ie, di framework. caller should ever ask di framework provide/construct/configure objects.