This repository was archived by the owner on Apr 29, 2025. It is now read-only.
-
-
Notifications
You must be signed in to change notification settings - Fork 0
Thinking of Module vs Plugin #2
Copy link
Copy link
Open
Description
modularization mains:
- cold module load
- module can call each other
- module may cause host app crash
- module is static for the app
- module may need isolation ( data and service isolation, not Type/Assembly isolation )
plugin mains:
- cold plugin load
- cold plugin unload
- hot plugin load
- hot plugin unload
- must need Type/Assembly isolation
- plugin may need to call each other
- plugin may need to modify the parent plugin host app.
- plugin must not cause host app crash! (the plugin itself can crash)
- plugin is dynamic for the app
problems
- hot plugin unload is limited (emit stuff can not be used)
- assembly isolation is hard : while we need some framework type in the plugin's host app (a framework type may not in the host app or a framework.extensions type is inside a plugin too [consider of , self-contained, different runtime (desktop runtime, server runtime and .net 6 introduce an assembly missing that is
System.Drawing.Common) ]) - Plugin call each other has the same problem like problem 2
- A type shared across host app and plugin , then it can not be isolated to it's child plugin.
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
No labels