Skip to main content

Publish and install

Up until this point, we've been testing our plugin only locally. We've verified that all our metrics are registered and the values are updated.
So in this section, we are going to publish the plugin and actually install it to MoBro to see if everything actually works as intended.

Preparations

In order to install the plugin to MoBro we need to publish it and then pack it as a .zip file.
But before we can do that we first need to make a few additions to our .csproj file:

  • Every plugin must be versioned, so let's set the version to 0.0.1
  • We need to set EnableDynamicLoading to true or else MoBro won't be able to load our published assembly and instantiate the plugin
  • Set UseAppHost and SelfContained to false, as we don't need to generate an .exe
  • The mobro_plugin_config.json needs to be copied to the publish directory as MoBro requires it to be present
Plugin.Example/Plugin.Example.csproj.js

<Project Sdk="Microsoft.NET.Sdk">

<PropertyGroup>
<TargetFramework>net7.0</TargetFramework>
<VersionPrefix>0.0.1</VersionPrefix>
<Nullable>enable</Nullable>
<OutputType>Exe</OutputType>
<EnableDynamicLoading>true</EnableDynamicLoading>
<UseAppHost>false</UseAppHost>
<SelfContained>false</SelfContained>
<ImplicitUsings>enable</ImplicitUsings>
<Nullable>enable</Nullable>
</PropertyGroup>

<ItemGroup>
<Content Include="mobro_plugin_config.json">
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
<CopyToPublishDirectory>PreserveNewest</CopyToPublishDirectory>
</Content>
</ItemGroup>

<ItemGroup>
<PackageReference Include="MoBro.Plugin.SDK" Version="0.3.0" PrivateAssets="all"/>
</ItemGroup>

</Project>

Publish a .zip file

Now that that's taken care of, we are going to publish our plugin.

CLI

The easiest way to publish a plugin as a .zip file is by using the MoBro Plugin CLI.
A simple invocation of the publish command from within the project directory is all it takes:

mobro publish .

After executing the publish command we should see the example_plugin_0.0.1.zip file added in our folder structure:

Plugin.Example
├── bin
├── obj
├── example_plugin_0.0.1.zip
├── Plugin.cs
├── Plugin.Example.csproj
└── Program.cs

That's it, we successfully published our plugin as a .zip file of just 4KB!

Manual

info

This section outlines a way to publish our plugin without the CLI. If you already published the plugin by using the CLI you may skip this section of the tutorial.

To publish our plugin without using the CLI, execute the following command within the project directory:

dotnet publish --framework net7.0 --runtime win-x64 --self-contained false --configuration Release -p:DebugType=None -p:DebugSymbols=false -p:GenerateRuntimeConfigurationFiles=false --output ExamplePlugin_v1 .

That should have created a new ExamplePlugin_v1 folder in your project so the structure should now look like this:

Plugin.Example
├── bin
├── obj
├── ExamplePlugin_v1
| ├── mobro_plugin_config.json
| ├── Plugin.Example.deps.json
| ├── Plugin.Example.dll
├── Plugin.cs
├── Plugin.Example.csproj
└── Program.cs

As you can see we've successfully created a Plugin.Example.dll. The name of the .dll file must match the one we configured in our mobro_plugin_config.json under assembly. That is the case, so we are good to go.

We've marked the SDK as private asset, did not include any other dependency and didn't generate an .exe either.
So our published plugin is just a 7KB .dll and two .json files. Nice!

The Final step is to pack everything into a single .zip file and removing our published folder just to tidy things up:

& "C:\Program Files\7-Zip\7z.exe" a -tzip "ExamplePlugin_v1.zip" ".\ExamplePlugin_v1\*"

rm -r .\ExamplePlugin_v1

If you don't have 7-Zip installed, you can also just manually zip the contents of the ExamplePlugin_v1 folder. It will produce the same result.

That's it: our plugin is now packed as a .zip file of just 5KB!

Install

Now that we've published our plugin, all that is left to do is installing it to MoBro to see if everything actually works.
For this to work, MoBro must be installed and running on the PC.

CLI

Installing a plugin for testing purposes can again be achieved by a single CLI command. We just pass the .zip file we've published in the previous step as an argument to the install command:

mobro install .\example_plugin_0.0.1.zip
tip

If you just quickly want to install your plugin to test some changes and don't actually need the published .zip file, you can also skip the publish step and just install the plugin directly from the project directory:

mobro install .

Manual

info

This section outlines a way to install our plugin without the CLI. If you already installed the plugin by using the CLI you may skip this section of the tutorial.

To install a plugin without the CLI we will utilize the REST API provided by the MoBro data service. All we need to do is execute a simple POST request to localhost:42069/api/plugins with a form-data body containing the unique plugin name as specified in the mobro_plugin_config.json as well as our .zip file.

We're going to use Postman to send that POST request:

Postman

As we can see the installation request was a success, and we got the newly installed plugin back as a response.

MoBro

If we switch over to MoBro we can see a new unknown plugin named "Example Plugin" that is running:

Running plugin

So our newly created plugin works!

If we check the settings, we can see that the "Update frequency" setting we defined is there as well:

Settings

And finally let's have a look at the metric explorer to check on our metrics:

Metric explorer

All our metrics are there and the 'CPU usage' and 'Memory in use' ones are constantly updated according to the 'Update frequency' configured in the plugins settings.

Metric Types & Units

Since we've used metric types provided by the SDK (CoreMetricType.Usage and CoreMetricType.Data) the values of our metrics already use the correct units. The memory data metric (where we provided the values in bytes) is even automatically converted to the appropriate higher unit (MB in the case of the screenshot above).

All the while we didn't need to bother with specifying units or conversion rates.
Simply providing the value was enough.

More on predefined metric types, units, etc. under Reference: Metrics.