I’m excited to announce that a C# plugin bridge for Objo Studio is now in active development and is planned for the next release. This has been one of the most requested features (you can follow it at Support third party packages) and it opens Objo up to the enormous ecosystem of .NET and native libraries.
How it works
A plugin will be a small C# wrapper, built against a new Objo Plugin SDK, that exposes ordinary Objo classes (i.e. constructors, methods, properties, typed events and more) which you then call from normal Objo code. The wrapper can sit on top of existing .NET code, or call native C/C++ libraries through .NET interop, with the correct binaries for each OS and architecture bundled inside the package. Plugin authors need C#/.NET tooling; plugin users need nothing but Studio.
For plugin developers
- Wrap existing .NET libraries or native libraries without giving out source code as plugins ship compiled.
- Expose namespaced classes with constructors, shared and instance methods, read/write properties, typed notification events (including progress), awaitable async methods, arrays, binary buffers and object types with proper disposal.
- Write descriptions once in C# and they show up in Studio’s autocomplete, hover tooltips and signature help.
- Package everything (API metadata, the compiled wrapper, managed and native dependencies) into a single
.objopackagefile you distribute from your own website. Dependencies are pinned to exact versions, and shared types can pass between your own plugins without conversion. - A dedicated Plugin SDK documentation section with a beginner tutorial, porting guides for existing .NET/C/C++ code and a complete reference.
One important note if you developer and ship Xojo plugins today: existing Xojo plugin binaries are not compatible with this SDK. You can reuse the underlying libraries, but they need a new C# wrapper exposing an Objo-facing API.
For Objo Studio users
- Install a plugin by downloading it and double-clicking or dragging it into Studio. No terminal, no DLL copying, no restart. Dependencies that ship with the download install in the same step.
- Manage plugins in the new global Plugin Library: multiple versions side by side, explicit updates, removal, and everything survives Studio upgrades. You can also add a plugin directly to a single project without installing it globally.
- Plugins work in Desktop, CommandLine, Web server and Worker projects, with full type checking, completion and help in the code editor.
- Published apps are self-contained: your customers install just the app, so no Studio, no plugins, no separate .NET runtime. Solutions also carry the exact plugin archives, so a project reopens and builds anywhere without reinstalling anything.
Not in this first version
To set expectations honestly: plugin code does not run in the visitor’s browser. This means that in web projects, plugins run on the web server and deliver results through your app’s normal web APIs. Also not included are visual designer controls and IDE extensions, an online registry/marketplace (plugins are distributed directly by their authors), automatic dependency downloads, and automatic wrapping of arbitrary .NET APIs - the wrapper defines exactly what it exposes. These will come in later versions of the SDK.
Implementation is well underway on the engine-side SDK contracts, and I’ll share more details - including the full Plugin SDK documentation - as development wraps up. I have been working on this feature for a few months in a separate branch. I have heard people’s requests for this so I’m grateful for your patience.
