Choose an extension model
Decide what belongs in a BASIC library, a composed visual control or a C# component.
Start with the smallest public surface#
| Model | Good fit | Working lesson |
|---|---|---|
| BASIC Library | Shared calculations, transformations and reusable nonvisual behavior. | MoneyTools |
| BASIC UserControlLibrary | A group of controls with a small public property/event contract. | CustomerCard |
| C# Component | A control or service whose implementation needs the managed component SDK. | C# lifecycle component |
A reusable component should expose what the consumer needs, not every detail of how it is built. A customer card can expose CustomerName and OpenRequested without exposing the inner TextBox and CommandButton.
Separate four contracts#
- Design metadata tells the Inspector and Toolbox what can be configured without running arbitrary component code.
- The public API defines property types, procedure parameters and events available to BASIC.
- The runtime implementation performs the actual work inside the generated application.
- The package declares identity, version, target support, files, dependencies and trust evidence.
Passing one boundary does not prove the others. A package can have valid metadata and still fail its runtime test. A working local assembly is not automatically a trusted distributable package.
Version the contract deliberately#
SDK API version 1.0 identifies the host contract. Your package version identifies your own release. A change to a public member type, direction or meaning can break consumers even when the assembly still loads. Keep stable component IDs and record compatible versus breaking changes before releasing an update.
Build, admit, consume#
Follow the authoring lesson for your model, then the package workflow. Test the package from a separate consumer project, with a fresh lock/cache resolution. That proves you did not accidentally rely on source files from the authoring project.
20f4bfed6b · Build manifest