Set up

A plug-in builds with the .NET 10 SDK on Windows, macOS or Linux, against the OpenBI SDK’s NuGet package from its zip. To run it you need OpenBI Studio on Windows or a Mac.

What you need

• The .NET 10 SDK, 10.0.100 or later, from Microsoft’s .NET download page.
• An editor: Visual Studio Code with C# Dev Kit, JetBrains Rider or Visual Studio.
• The OpenBI SDK: OpenBI-SDK-0.3.74.zip, from www.openbi.no/sdk/.
• To run a plug-in: OpenBI Studio 0.3.74 or later, on Windows (x64) or on a Mac with Apple silicon. There is no OpenBI Studio for Linux: on Linux you build and test, and run the plug-in in the studio on Windows or a Mac.

The first build downloads ModelContextProtocol 2.2.0, the MCP library the studio uses, and what it needs, from nuget.org.

The SDK’s zip

Check the zip against the SHA-256 the download page shows, then unzip it. It holds one folder, OpenBI-SDK-0.3.74/:

Get-FileHash OpenBI-SDK-0.3.74.zip

shasum -a 256 OpenBI-SDK-0.3.74.zip

packages/OpenBI.Studio.Sdk.0.3.74.nupkg

The SDK as a NuGet package: what a plug-in builds against. Its build targets write the contract your plug-in is built against into its assembly.

nuget.config

Makes packages/ a package source for projects inside the folder.

lib/

The same assemblies for a plain reference: OpenBI.Studio.Sdk.dll with its XML documentation, and OpenBI.Studio.Core.dll, the types the contract uses, as a reference assembly (their signatures, no code: in the studio, the studio’s own copy runs).

samples/HelloWorld/

The SDK’s example: the smallest plug-in, with two agent tools.

README.md, SHA256SUMS.txt

The SDK’s guide, and every file’s SHA-256.

The package source

A project inside the SDK’s folder finds the package through its nuget.config. For a project elsewhere, add the SDK’s packages folder as a package source once:

dotnet nuget add source <the SDK's folder>/packages -n openbi-sdk

Or put a nuget.config beside your projects that names it, as Your first plug-in does.

A plug-in’s project

A plug-in is a plain net10.0 class library. What matters in its project file:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net10.0</TargetFramework>
    <Nullable>enable</Nullable>
    <ImplicitUsings>enable</ImplicitUsings>
    <Version>1.0.0</Version>
    <EnableDynamicLoading>true</EnableDynamicLoading>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="OpenBI.Studio.Sdk" Version="0.3.74" ExcludeAssets="runtime" />
  </ItemGroup>
  <ItemGroup>
    <None Update="plugin.json" CopyToOutputDirectory="PreserveNewest" />
  </ItemGroup>
</Project>

• EnableDynamicLoading: the plug-in is loaded at run time, its own dependencies beside it.
• ExcludeAssets="runtime": the SDK’s assemblies and ModelContextProtocol are not copied to your output. In the studio, the studio’s own are used.
• plugin.json goes to the output beside the assembly (see plugin.json).

Tabs in a second project

A tab’s view is whatever the studio shows: on Windows a WPF FrameworkElement, a UserControl for instance. Keep the logic and the agent tools in the plain net10.0 library, and put the views in a second project on top of it:

<PropertyGroup>
  <TargetFramework>net10.0-windows</TargetFramework>
  <UseWPF>true</UseWPF>
  <EnableWindowsTargeting>true</EnableWindowsTargeting>
  <EnableDynamicLoading>true</EnableDynamicLoading>
</PropertyGroup>

EnableWindowsTargeting lets the views project build on macOS and Linux too; it runs in the Windows studio. Customer Service is made this way (see How it is built). The Mac studio shows an Avalonia Control instead; no plug-in Norway Analytics ships has an Avalonia view yet. A view of the wrong kind shows a note in its tab, and the plug-in’s agent tools work either way.

On each system

Last updated 3 November 2026 · OpenBI Studio 0.3.74