DryIocZero: Add support for handling dynamic assembly loading and unloading

[tapika]

I'm not sure if this can be implemented - but it would be nice to support multiple assemblies by one
DryIocSize compilation - but then either using T4 template or anykind of tool much be able to pre-cache assembly type information.

For example application can have 200 assemblies, and it would be useful to precache all of them, just in case one assembly changes, but not the rest.

Also some of assemblies needs to be configured as plugins (maybe by folder name) - their information will be fetched only if particular assembly is loaded. If assembly is unloaded - then DryIocZero should not provide it's information as well.

Suspect here are two new requirements.

[dadhi]

@tapika Hi, thanks for asking

1. Currently, there is no limitation on the assemblies number - it is what user can specify to load.
2. Scanning the assembly folders is not supported out of the box - you may use a separate tool like MEF discovery or brew your own.
3. A plugin system likely can be built on top of the DryIoc core features (I think probably someone already done that - probably worth asking on SO).
4. In regard to the assembly unloading, it is not possible in principle for the DryIocZero because it is one-off assembly scanning during the code compilation. Instead, you may use DryIocZero for the common services and load dynamic plugins/assemblies using the runtime part of the DryIoc.

Generally, I would love to see the experimentation in this area. I am planning to develop more ergonomic compile-time features based on the DryIocZero. Possibly using the source code generation or t4 from the Mono, see #214
I welcome any ideas in this area. The plan for those after the v5 is realised (in the coming days).

[tapika]

I by myself haven't used yet DryIocZero container. Originally I've found good comparison between different IoC containers, and even raised some tickets related to that one to https://github.com/Caliburn-Micro/Caliburn.Micro/issues/795 Caliburn Micro (quoting as code, so this ticket would not reference Caliburn Micro git).

I'm planning to analyze assembly loading and unloading issues in depth and maybe will return to them within my own
https://github.com/tapika/swupd choco (swupd) fork.

As for Ioc containers - choco has Autofac, Caliburn Micro, SimpleInjector in use. I would prefer to have one good IoC container, not 3.

I was thinking that if I'll go from user interface perspective - then Caliburn Micro would be still built in into UI. (Unless I find a really clever way to chop it off).

Were you ever thinking about taking Caliburn Micro and merge DryIocZero container features ? Or alternatively take Caliburn Micro features and build them into DryIocZero ? Or just start from scratch and pick up best pieces of two libraries ?

My own requirement - support of 200x assemblies - this is more or less reality for one of projects I'm working on, and incremental build needs to be fast. Taking into account that besides managed assemblies there could be also native dll's mixed in, and dislocated in multiple folders across main application root folder. And dynamic load/ unload needs to be supported eventually.

But concerning containerizing in general - here is also one example where I would like to drive containerizing:
https://github.com/Caliburn-Micro/Caliburn.Micro/issues/797. Does not relate to this discussion, maybe even separate subject.

[ErisApps]

I've been toying around with assembly/module loading/unloading based on following 2 MS docs links:

• https://docs.microsoft.com/en-us/dotnet/core/dependency-loading/overview
• https://docs.microsoft.com/en-us/dotnet/standard/assembly/unloadability

However, during my toying around... I noticed that when utilizing the Unregister method (both generic and non-generic variants), it will keep a reference to the ServiceType in Container._registry.Value.Services (but with the implementation type "punched out"), preventing a successful unload of the assembly/module.

[dadhi]

@ErisApps You mean that I need to drop the registry during Dispose? mm.. I think you're right.

[ErisApps]

I need to expand my own demo project some more in order to properly show what I mean.
But it basically boils down to this, however... it might very well be that I'm missing something crucial here so I'm all ears on this.

[dadhi]

yeah, it make sense to drop the registry. may be it will kick in the gc.

[ErisApps]

For completeness sake, here's the updated demo project:
https://github.com/ErisApps/POI.ModuleTest/tree/feature/DryIoc_integration
Could possibly also help as a playground for testing on your end as well.

[ErisApps]

Out of curiosity, but any news on this?

[dadhi]

In progress, I did not forget :)