C# Plugins are coming to Objo Studio!

Objo
1

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 .objopackage file 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.

2

@einhugur or @MonkeybreadSoftware

Would this be of interest to either of you guys?

3

Kinda funny this comment has survived for 10 hours! Kudos to MonkeyBread Software & Plugins - #5 by Andreas_Michelk - General - Xojo Programming Forum

Screenshot 2026-09-30 alle 19.00.04
Screenshot 2026-09-30 alle 19.00.04799×277 23 KB

4

I will reach out to @MonkeybreadSoftware once the Plugin SDK is released. It’s pretty much working (V1 at least) on my dev branch right now.

5

Yeah, Monkeybread is absolutely phantastic as a plugin provider, in terms of product quality and customer service.

6

Indeed. I subscribed for their ODBC provider some years ago when I still held a Xojo license as word on the street was that Xojo’s native Sql Server provider was a bit squirrelly and MB thought that ODBC was the safer route for me on Windows Server. I could not get it to work, though, so the proprietor logged into my work VM and installed some utilities and diagnosed his way to a working installation. I was suitably impressed. I did not renew MB only because I just needed it temporarily to quickly get an existing Xojo prototype working while I had time to build something more permanent with Visual Studio (I ended up doing WinForms since it was a Windows-only shop and I knew it well).

I wish I had Objo available to me then, as my client doesn’t know or care how I build things for them really so long as it can use their existing Sql Server infrastructure and provide an internal API for their web app developer to call into. I would definitely have used it for the administrative utilities and likely the ETL processing pipeline – maybe not for name / address / postal service standardization, servicing the web site and DB loading, although if I were at that stage of making decisions today, I think the C# integration would allay most of the reservations I would have had at the time even in those areas.

The main problem I would probably have had would be that my eventual collaborators and/or successors would be unfamiliar with non-MSFT tooling, but Objo is such a pleasure to work with that I think I could convince people they could use it without getting cooties. I might have to agree to give job references that elide the presence of Objo in our stack though, lol. I’m a realist, after all. Developers like to style themselves as individualists, but way too many of them fear being thought of as uncool [sigh].