Skip to content
This repository was archived by the owner on Apr 29, 2025. It is now read-only.

Thinking of Module vs Plugin #2

@John0King

Description

@John0King

modularization mains:

  1. cold module load
  2. module can call each other
  3. module may cause host app crash
  4. module is static for the app
  5. module may need isolation ( data and service isolation, not Type/Assembly isolation )

plugin mains:

  1. cold plugin load
  2. cold plugin unload
  3. hot plugin load
  4. hot plugin unload
  5. must need Type/Assembly isolation
  6. plugin may need to call each other
  7. plugin may need to modify the parent plugin host app.
  8. plugin must not cause host app crash! (the plugin itself can crash)
  9. plugin is dynamic for the app

problems

  1. hot plugin unload is limited (emit stuff can not be used)
  2. 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) ])
  3. Plugin call each other has the same problem like problem 2
  4. A type shared across host app and plugin , then it can not be isolated to it's child plugin.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions