Runtime & concurrency
Reveal answer and reasoning
Start by deciding whether the allowed extension set is known at build time. For a bounded set, use explicit factories or generated registration so constructors and behavior are reachable deliberately. If reflection is needed, state the exact members required and propagate appropriate annotations through the Type values rather than preserving everything indiscriminately. Validate compatibility and construction separately from external-key selection.
Publish the intended native target in an environment with its real prerequisites, review warnings without automatically suppressing them, and execute the resulting artifact before making a support claim. Test valid activation, unknown registration, incompatible types, and failure paths. The wrong design proves only a JIT run, silences analyzer warnings, and promises arbitrary plugins or runtime code generation that the chosen deployment model does not support.
Record publication scope honestly; a good annotated design is a useful starting point, not evidence that an unbuilt artifact worked.
What a strong answer covers
- Bound or generate registrations where possible.
- Preserve exact required metadata deliberately.
- Validate the actual published target before claiming support.
Common pitfall
Suppressing deployment warnings and inferring native compatibility from a successful JIT execution.
Follow-up questions
- What if the product truly requires new assemblies after deployment?
- How would a capability guard choose a supported fallback?
Self-review
Choose what to revisit. These marks are your own assessment and are separate from lesson completion.